¿SCRUM es poderoso o es eficiente?

¿Por qué SCRUM es más eficiente que las metodologías tradicionales?

Si creemos que Scrum es poderoso porque es una religión…

Scrum es todopoderoso porque es nuestra religión. Si quieres alcanzar el cielo de la tecnología, ese lugar idílico donde todos los proyectos finalizan en plazo, debes seguir puntualmente cada uno de sus ritos.

En los tiempos oscuros, los profetas Brooks y DeMarco nos advirtieron que nos enfrentamos a problemas extremadamente complejos en los que podemos trabajar por los siglos de los siglos. Inspirados por el espíritu de los nuevos tiempos propusieron abordar la solución mediante pequeñas iteraciones, analizando junto con el cliente qué se ha conseguido en cada una de ellas y qué se debería hacer a continuación.

El ritual SCRUM que nos inspiraron es como sigue:

El Account Manager descubre una necesidad del cliente y junto con el Sumo Sacerdote o Product Manager, preparan una oferta que tiene plazo y presupuesto definidos pero cuyo alcance queda indeterminado. Realizan sacrificios a Poseidón y ofrendas a Baco para que el cliente la firme.

La Sagrada Firma es el ritual más complicado y al que menos atención se presta en los Textos Sagrados. Los clientes no iniciados se resisten a comprometer presupuestos determinados a cambio de productos indeterminados. Es inútil explicarles que en los proyectos realizados según los ancestrales ritos de Waterfall, aunque el alcance estaba definido, en media sólo se entregaba el 50% de lo especificado.

Tras la Sagrada Firma, en un concilio, cliente, Account ManagerProduct Manager, y Product Owner, hacen una descripción de alto nivel del sistema en las tarjetas sagradas llamadas Epics y Features, que describen las principales funciones del sistema en un párrafo. El Product Backlog es un altar de corcho donde se exponen a los fieles las sagradas tarjetas para que puedan consultarlas a voluntad.

En sucesivos aquelarres, el Product Manager y los programadores, descomponen Epics y Features en nuevas tarjetas llamadas Historias de Usuario, que tienen la forma ‘Como usuario <perfil de usuario> soy capaz de hacer <tarea> y así consigo <valor para el negocio> ’. Exponen a los fieles su trabajo en un nuevo altar de corcho, el Team Backlog.

Es el momento de comenzar los ritos de implementación.

El primero es formar los escuadrones de desarrollo, con un Product Owner, un Scrum Master y entre tres y cinco consultores. Sus puestos de trabajo deben estar próximos entre sí y se encargarán de implementar de extremo a extremo las Historias de Usuario de una parte concreta de la aplicación. Deberán definir la arquitectura, hacer el diseño, codificar, probar, integrar y documentar.

Cada iteración comienzan con la ceremonia del Sprint Planning. El squad se reúne con el cliente para decidir qué Historias de Usuario van a intentar implementar durante el Sprint, que durará entre tres y cuatro semanas. El cliente sabe qué historias de usuario son prioritarias. El squad tiene una estimación de su velocidad de ejecución.

Todas las mañanas del sprint, el squad se reune para maitines, también conocido como daily. Durante el resto del día, diseñan las Historias de Usuario, las codifican, desarrollan las pruebas unitarias y prueban el software construido. Sólo si el código supera las pruebas se considera finalizado y apto para entregar al cliente.

El Product Owner ayuda a los programadores a interpretar las sagradas Historias de Usuario. El Scrum Master vela por la pureza de los rituales.

Finalizado el Sprint, el squad celebra el Sprint Review, ceremonia en la que el código desarrollado se entrega al cliente y las Historias de Usuario que no se han completado se devuelven al team backlog.

La ceremonia final es el Sprint Retrospective. Aquí Product Owner, programadores y testers reconocen sus faltas y hacen propósito de enmienda, con el fin de mejorar sus habilidades y ser más productivos en las siguientes iteraciones.

Sigue religiosamente este ritual y tus proyectos llegarán a buen puerto con la bendición de los Dioses.


Los tres errores más comunes al implantar Scrum

¿Cuales son los principales errores que se cometen al implantar Scrum?

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 respectivas.

Y tiene sentido, ¿por qué hacer el mismo trabajo en bloques de tres semanas iba a mejorar la productividad? Scrum es mucho mas que hacer sprints o un tablero lleno de post-it. Vamos a repasar los errores más comunes que se cometen en estas primeras experiencias.

1. No subir los desarrollos a producción después de cada sprint.

Quizás el error más recurrente y también el más importante. Asume que tu cliente no sabe 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. En la metodología tradicional se muestran los resultados al final del proyecto y se comienzan las modificaciones cuando ya no queda presupuesto.

Además, como la inversión económica de un sprint es pequeña y tu cliente utiliza las nuevas funcionalidades antes, su retorno de inversión -ROI- es mucho más rápido, música celestial para cualquier CFO.

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 clásico. Si te has equivocado en la estimación y no es viable finalizar los trabajos, ¿cuales son las posibles opciones?

a) Puedes pedir al equipo que haga un sobreesfuerzo y trabaje más horas.

b) Puedes rebajar la calidad y entregar algo que parece que funciona, pero sin hacer pruebas de regresión.

c)  Puedes rebajar el alcance y hacer menos funciones.

Debido a la inercia cultural, la mayor parte de los proyectos comienzan por la opción a) y terminan por b). Sin embargo Scrum establece que la respuesta correcta es la c).

Una parte de los incrementos de productividad en Scrum proceden de eliminar la presión de trabajo de los consultores. Otra parte se consigue con menos incidencias en producción.

3. No tener un Product Owner integrado en el equipo.

El Product Owner es una figura clave en Scrum y al él se debe también una parte del incremento de productividad.

Los programadores trabajan sin una especificación detallada, así que constantemente tendrán dudas sobre la funcionalidad a desarrollar. Es imprescindible que alguien familiarizado con el negocio esté con ellos durante todo el proceso de desarrollo.

Además el Product Owner es el guardián del funcional, quizás no sabe programar pero entiende el valor añadido que aporta cada función al negocio. Si es capaz de priorizar dentro del sprint aquellos desarrollos que aportan más valor, conseguirá un retorno de inversión más rápido en cada iteración.

Si el Product Owner no está integrado en el equipo, los programadores serán más lentos, las modificaciones a lo ya desarrollado serán más frecuentes y el valor para el negocio de cada sprint será menor.

Aunque estos sean los tres errores más habituales e importantes, hay otros muchos que se pueden cometer al comenzar a implantar Scrum. Sin ánimo de ser exhaustivos:

- Hacer una especificación pesada. En Scrum se pasa de una idea de alto nivel a la especificación de detalle que hacen los programadores. ¿Para que emplear meses en una especificación de bajo nivel si damos por sentado que el cliente no sabe lo que quiere?

- Solicitar que el cliente valide la especificación. Aunque firme la especificación, sigue sin ser lo que necesita, y lo sabe. Tu equipo puede estar varias semanas de brazos cruzados antes de que el cliente de su consentimiento. ¿No es mejor emplearlas en presentarle una parte del desarrollo?

- Mantener las jeraquías dentro de los equipos. Ni el Jefe de Proyecto se transforma en Product Owner ni el Líder Técnico en Scrum Master. De hecho la figura de Líder Técnico desaparece; todos los programadores colaboran desde un plano de igualdad y ninguno puede imponer su criterio a los demás. El Jefe de Proyecto también se difumina; ya no es necesario negociar alcance y plazo de cada desarrollo, el control económico es mucho más sencillo y las funciones de motivación pasan al Scrum Master.

- No automatizar las pruebas a la vez que se hacen los desarrollos. Esto impedirá hacer pruebas de regresión y los sprints tendrán paulatinamente menos calidad, o menos funcionalidad. Si no automatizas las pruebas, ¿cómo piensas hacer DevOps?

- Tener a los equipos separados geográficamente. Recuerda que los equipos están creando la especificación mientras hacen el desarrollo. Si están separados ¿cómo van a transmitirse este conocimiento?

- No hacer retrospective. Celebrar los éxitos del sprint y analizar los puntos de mejora aporta cohesión y les permite crecer como equipo. Si no hay estos espacios para la reflexión, ¿cómo van a mejorar en la aplicación de la metodología?