Scrum, Scrum y más Scrum

Bien, después de una semana sumamente interesante, donde parecen haber concluído algunos procesos (como el conflicto con el campo, que espero se termine, y más allá de las diferencias y temas por resolver pendientes, el país "camine"), se dio particularmente una semana Scrum en mi caso, con un curso práctico -corolario de otro teórico que hiciera hace un par de semanas- más un encuentro con otros arquitectos, en el cual se compartieron experiencias, opiniones y se debatió sobre pros y contras de Scrum, hicieron que en mi cabeza se agolparan unas cuantas ideas que no tenía hasta la semana pasada.

El juego en acción

La práctica del curso de Scrum de Angel "Java" López fue muy interesante. Me vi jugando al scrum (decir esto me hace acordar al "Scramble") con un equipo que tenía consignas precisas, aunque no detalladas.

El objetivo del equipo era desarrollar, un juego que sirviera para enseñar los propósitos del scrum. Honestamente, cuando vi los objetivos, fue una total falta de fe en obtener algo concreto. Los primeros momentos fueron de confusión y debates más largos de lo esperado (aunque no muy extensos, en realidad), pero en eso Angel se puso firme en tratar de mantener el concepto de "timebox". Este es un concepto interesante, que usan las metodologías ágiles, y que buscan "poner en caja" el tiempo usado para cada tarea.

El tiempo en una caja

Si proponemos a un equipo que discuta sobre un problema a resolver, y lo dejamos un buen rato, y volvemos a verlos más tarde, es probable que al interrumpirlos y preguntarles a qué conclusión llegaron o que resolución tomarían, todavía no haya un acuerdo o bien se desviaron del tema original porque había otros "problemas laterales por resolver".

Si le dejamos a un desarrollador que desarrolle una tarea específica, pero con ciertas libertades o ambigüedades, y lo dejamos solo por un tiempo, al verlo nuevamente y revisar que hizo, es probable que lo haya terminado, pero que no haya hecho exactamente lo que se le pidio, o se trabó con algo y directamente abortó el desarrollo, o hizo lo que se pedía pero con una docena de adornos más que, en el mejor de los casos, ayuda sin obstruir al pedido inicial.

Estas dos situaciones, hipotéticas, no apuntan a desmerecer el valioso trabajo de un equipo o un desarrollador o cualquiera sea el caso; sino a que, ante la falta de un objetivo específico, o de un límite de tiempo, etc, cualquiera se distrae, o se traba, o se va por las ramas, teniendo en cuenta además de que hay otros factores en el medio (motivación, problemas de recursos, etc)

Y teniendo en cuenta que muchas veces, los requerimientos que podemos obtener tienen límites difusos o temas sin resolver o analizar... hace que los tiempos se disparen. Entonces, ¿qué mejor que poner en una caja el tiempo? Si cambiamos estos 2 planteos por "hay que resolver este problema, el tiempo disponible es 2 horas", estas personas sin dudas dirigirían todos sus esfuerzos y enfoque destinado a que al término de esas 2 horas, tengan algo, aunque sea erróneo.

¿Y si nos equivocamos?

Y aquí me detengo en otro punto. El miedo al error. Esto nos hace sobreanalizar muchos temas, nos hace adelantar varias jugadas como un jugador de ajedrez, lo que muchas veces nos hace olvidar el problema inmediato que tenemos enfrente. Tenemos miedo al error. Tenemos miedo de implementar algo que no sirva, o que sea de "mala calidad".

Ponernos un milestone rígido, atenta posiblemente contra la calidad de resultado, pero nos brinda otra cosa: la posibilidad de avanzar y revisar continuamente la dirección tomada. La consigna es "no hay mas tiempo para discutir, hagamos esto veamos que pasa". Total, el punto de control es pronto, y entonces, pronto nos daremos cuenta si sirve o no.

El problema es que seguimos pensando con un enfoque tradicional, prescriptivo, analizando previamente todas las alternativas, y creyendo que debemos evitar de antemano algo que, posiblemente termine 2 meses después.

Agiles como peces en el agua

Y aquí es donde se nota la mano de "ser ágil", o, si prefieren, seguir la movida ágil. Porque las prácticas de iteraciones continuas y con períodos cortos, nos dan la posibilidad de medir continuamente si tomamos la dirección correcta, pero nos fuerza a avanzar y no quedarnos inmovilizados con trabas o divagues.

Posiblemente estos conceptos, no sean aplicables en todos los casos. Habrá casos (y de esto he hablado en todo lo relacionado al movimiento "Slow") en que Scrum no sea aplicable, que metodologías ágiles no sean aplicables, aquí la cosa parece un espiral de velocidad. Pero no lo es tanto... En otras metodologías sufrimos presiones y debemos meter, no sólo tiempo en una caja. Debemos meter, tiempo, alcance y costos en una caja, que por lo general, alguna de las 3 variables, se escapa... y ni hablar cuando se escapa más de una, explota con caja y todo.

Aquí se trata de sacar el "alcance" de la caja. Pero dejemos dentro el costo y el tiempo, debemos saber administrar los recursos eficientemente.

Fin del juego

Bueno, para resumir, porque llegué a mi "fin de tiempo" para escribir este artículo :), el juego resultó muy interesante. En 2 sprint virtuales, de media hora de duración cada uno, armamos un juego con tablero, cartas, y reglamento escrito con todas la reglas.

Honestamente, no creí desde el principio que lo obtendríamos. Creí que nos íbamos en divagues y que a los sumo, tendríamos algunas reglas o ideas escritas nada más. Pero aplicamos los conceptos que comenté en este artículo y las cosas fluyeron. Se notó incluso, el esfuerzo del equipo y aceleramos cuando hubo que acelerar. Me sentí haciendo fuerza en la montonera del scrum de rugby ;)