Hace unas semanas en una reunión con un colega, el mismo me comentaba que estaban desarrollando proyectos en su lugar de trabajo utilizando metodologías ágiles, algo que para mi fue casi que música para mis oídos.

Al indagar un poco sobre la metodología específica, la cual mencionó que era “Scrum”, me comunicó que básicamente los cambios a como trabajaban anteriormente eran a nivel de las reuniones diarias y cortas que ahora llevaban a cabo.

Conocí Agile en 2010, mientras trabajaba en Admios en un proyecto para uno de los mayores agregadores bancarios del mundo. Antes de ese momento había escuchado el término, pero nunca le presté más atención de la que consideraba que fuese necesaria. En ese entonces, si me hubiesen hecho explicar que era Scrum, era probable que mi respuesta fuese muy similar a la de mi colega, llena de falta de entendimiento en la metodología / framework.

#.Estamos descubriendo mejores formas de desarrollar software …

En febrero de 2001, 17 personas se reunieron y crearon lo que conocemos hoy como el Manifiesto Ágil, lo que sentaría las bases para las metodologías ágiles que surgirían formalmente después, como Scrum, XP, DSDM, Crystal, entre otros.

Estas personas encontraron problemas comunes en la implementación de sus proyectos de software, los cuales se podían diferenciar de los proyectos que habitualmente desarrollaban. Es decir, llegaron a un punto en común en diferenciar los proyectos de software (y otros proyectos de conocimiento) de los proyectos sin altos grados de incertidumbre (o complejidad). Por ejemplo: no es lo mismo construir una carretera, luego de hacerlo mil veces que construir un software para resolver un problema específico y que jamás has resuelto.

Básicamente, descrubieron “mejores formas de desarrollar software”, tal como inicia el Manifiesto Ágil, que se adatpara conforme a lo que realmente necesitaban. Esto no quiere decir tampoco que Scrum funcionaría para todos los casos o que las metodologías tradicionales no funcionarían para algunos otros.

En la Fig. 1 (The Spectrum of Process Complexity ^fn-3) se muestra cuando es útil el uso de Scrum: cuando conocemos el problema, pero no la solución a este problema. Dicho esto, siempre será necesario, como practicante de Scrum (ya sea como el Equipo, como el Scrum Master o el Product Owner), entender realmente el problema que estamos resolviendo más que entender como lo vamos a resolver.

#.El Control de Proceso Empírico

Scrum se basa en un Control de Proceso Empírico, que permite que todas las decisiones se basen en “observación y experimentación, en vez de una planificación inicial y detallada”, esto basado en tres elementos principales:

• Transaprencia: Que permite que todos descrubran todo, de una forma fácil y organizada.
• Inspección: Que permite que todos sepan el estado de todo, en todo momento.
• Adaptación: Que permite, de acuerdo a las entradas (la inspección, que surje por la transparencia), evaluar y adaptarse en todo momento.

Las reuniones diarias, conocidas coloquialmente como “Daily Standup Meetings” (o Daily Scrum) solo involucran dos partes de este proceso:

• Permite la transarencia, ya que a través de la reunión, todos conocen que está haciendo que en un momento específico.
• Permite la inspección, puesto que me permite evaluar el estado actual de las tareas en un momento dado (no tanto como otros elementos de Scrum).

Sin embargo, también obvia (si se ejecuta erradamente) el tercer elemento, la adaptación, ya que puede que el equipo únicamente se reúne por reunir y no genera entendimiento y conocimiento para la mejora continua del resultado.

#.Scrum como un proceso incremental de entrega de valor

Analizado el espírito teórico del cual se basa Scrum (el Control de Proceso Empírico), es importante entender que Scrum es un framework, es un proceso y como tal tiene un flujo incremental y constante.

Aplicar Scrum no solo es reunirse a diario o entender la forma en que desarrollamos software, es comprender las expectativas del cliente (no lo que el cliente quiere, si no lo que el cliente necesita) y entregar estas expectativas de forma rápida, incremental e iterativa, por medio de un equipo auto-organizado y colaborativo.

A nivel de valor, es importante siempre entender que la priorización de estas entregas deben ser enfocadas en la entrega de valor, proceso conocido como “Value-based Prioritization”. Para ello, la voz del cliente (el Product Owner) debe entender el problema que se requiere, para así recibir una solución valiosa en forma oportuna y continua.

#.Entonces, ¿cómo aplicar Scrum en mi organización?

Luego de haber aplicado Scrum en múltiples organizaciones, la que mayores resultados positivos ha generado siempre es la siguiente.

Al momento de implementar Scrum, mejor es implementarlo inicialmente tal como es señalado en numerosos escritos previos, como la Guía Scrum ^fn-1 o la Guía SBOK ^fn-2 y luego, en base al Control de Proceso Empírico, ejecutar la Adaptación necesaria, conforme a las necesidades que vayan surgiendo.

Scrum no es un proceso cerrado: es un proceso abierto en toda su extensión. Requiere retroalimentación, la cual surje en casi todas sus Ceremonias ^fn-4, tal como se muestra en la Fig. 2. La única forma de saber que nos ayuda y que no, es probarlas inicalmente y luego modificar el proceso en base a lo que encontremos.

Al final y luego de muchas modificaciones, es muy común que en equipos mucho más maduros, terminen implementándose prácticas o reglas ^fn-5 de otras metodologías, como Programación en Pareja (XP, aunque usualmente se implementa a medias), Test Driven Development (o Test First, como señala XP), Collective Ownership (XP) o Tableros y Ciclos Kanban (Lean/Kanban).