Scrum
Una mirada orgánica sobre el mundo del trabajo
Por Alan Cyment
Este libro se trata sobre el trabajo. Sobre cómo nos organizamos para trabajar, hacer, producir. Mi intención es que reflexionemos sobre cómo encaramos nuestro trabajo y soñar alternativas. Alternativas contrastantes, radicalmente distintas. Pero para eso es necesario hacer primero un poco de introspección. Este libro intenta convertirse en una pausa, un espacio, una posibilidad. Un momento no para trabajar, sino para pensar el trabajo.
Baja el sol, es domingo, el fin de semana se aleja sin aún haber partido. Arrecia la melancolía, irrumpe el lunes con su lógica de rendimiento, tedio e inercia. Algo no funciona, pero estamos acostumbrados. Trabajar, para muchos de nosotros, es feo y necesario. Nuestro mayor anhelo no pasa de la mera supervivencia. Jefes agobiantes que transpiran ineptitud, objetivos incumplibles, reglas inexplicables, horas invalorables sentados entre cuatro paredes. Envidiamos a los fumadores porque, paradójicamente, son los que más tiempo pasan al aire libre. Y sin embargo, no todo está perdido.
Pero el trabajo también conlleva placer, bienestar. Disfrutamos el sabor de la tarea bien hecha. Sentimos una hermosa adrenalina ante el desafío. Percibimos esa electricidad inexplicable cuando ocurre, casi siempre de maneras inesperadas e irrepetibles, verdadero trabajo en equipo. Saboreamos la pausa, café de por medio, que permite reflexionar y reponer energía. Hay esperanza.
Pensemos en voz alta, preguntémonos, indaguemos aunque no tengamos la respuesta: ¿Quién toma las decisiones en los trabajos? ¿Quién decide en qué debemos trabajar? ¿Cada cuánto se decide en qué debemos trabajar? ¿Quién pone las reglas? ¿Cada cuánto se revisan esas reglas? Sigamos preguntando: ¿Qué tipo de labor disfrutamos más? ¿La conocida o la novedosa? ¿Aquella en la que somos expertos o aprendices? ¿La disfrutamos más si nosotros decidimos hacerla? ¿Cómo se dio el trabajo en equipo? ¿Quiénes estaban en ese equipo? ¿Podría haber sucedido con otra gente? ¿Sabían los otros hacer lo mismo que yo? ¿Teníamos todos el mismo objetivo o no? ¿Habríamos sido más o menos productivos tomando más pausas? ¿La respuesta a estas preguntas cambia cada día?
El cambio se acelera. Lo leemos, lo escuchamos, lo vivimos. Y sin embargo hay reglas, ideas, estructuras que se mantienen. A veces para bien, a veces no tanto. Por ejemplo, la manera de organizar personas para trabajar (¿management?) no ha cambiado radicalmente en los últimos 100 años. No ha cambiado ni en la empresa ni el estado. Esa filosofía, que vamos a tratar de degustar más adelante por amarga que resulte, permeó sin tapujos en innumerables aspectos de nuestra vida. El sistema educativo, sin ir más lejos, puede ser visto como una gran línea de producción, con niños ignorantes entrando por un lado y niños preparados saliendo por el otro. En un siglo llegamos a la luna, inventamos el avión y el microprocesador, nació internet, pero sigue habiendo managers. Evolucionó lo que producimos y cómo lo producimos, pero no cómo nos organizamos para producirlo. Necesitamos un nombre para esa manera clásica de llevar adelante el trabajo. Entre tantos posibles, nos vamos a quedar con Taylorismo, en honor a Frederick Taylor, su santo patrón. Taylor, era un ingeniero mecánico obsesionado, como tantos de su generación, en aumentar la eficiencia. Su propuesta, tan propia de un siglo XIX enamorado de la razón y el rigor científico, fue dividir de manera tajante el hacer y el pensar a la hora de producir. Nace como actor central el manager, único responsable de observar, analizar, diseñar y controlar la manera de trabajar de su alter ego hacedor, el empleado. El Taylorismo marcó un salto sin precedentes en la productividad, dando inicio a la era de la hoy cotidiana producción en masa. Deshumanizante y simplista para algunos, lógico y universal para otros, la sistematización del trabajo se convirtió rápidamente en el nuevo sentido común a la hora de organizar el trabajo. Pero el Taylorismo, con su moral incansablemente utilitarista, plantó la semilla de su propia corrosión. La ética eficientista no hizo más que transparentar, eventualmente, su techo productivo. Y es así como nos encontramos a nosotros mismos en esta paradoja. Nuestra ansiedad por aumentar la productividad, fogoneada por un siglo de moral Taylorista, se ve frustrada por los límites del sistema que nos trajo hasta acá. El mundo es hoy en día un lugar mucho más complejo que el mundo en el que vivió Taylor. Comunicados con las antípodas literalmente a la velocidad de la luz, con el comercio crecientemente desregulado y el taylorismo en las venas, hemos creado un mundo cambiante, incierto, mucho más líquido. Hablemos de ese mundo. Hablemos de complejidad.
Hablar sobre complejidad es, claro está, complejo, pero tal vez nos permita entender un poco más por qué el domingo muere siempre de tristeza. Intentemos. Podemos pensar la complejidad en términos de cuán conocidos (¡y conocibles!) son los distintos aspectos de nuestro trabajo. Y ya que tres es un número medio mágico, dividamos este análisis en tres secciones. Analicemos qué hacemos (el dominio, las necesidades, el usuario), cómo lo hacemos (las herramientas, los procesos, las técnicas) y quiénes lo hacemos (el equipo, las personas). Cuanto más lejos estamos en un eje, más desconocido es ese aspecto. Si nos vamos muy a la derecha, conocemos poco y nada sobre el cómo. Si nos quedamos bien bajito, tenemos relativamente claro el qué. 
Ahora dividamos el gráfico en áreas o clases de labores. Muy cerca del origen tenemos el trabajo obvio, que es eminentemente predecible, controlable y, claro está, un tanto aburrido y poco propenso a la innovación. En el otro extremo de la cuestión habita el enigmático caos. Repleto de posibilidades, repleto de peligros, repleto de incertezas. Una vez definidos los extremos, admitimos que la mayoría de nuestro trabajo sucede, como casi siempre, en el medio. Pero el medio no es todo igual. El espacio intermedio se puede dividir en dos terrenos muy, pero muy distintos. Tan distintos son que vamos a imaginarnos que los separa una zanja, una especie de agujero negro.
Arrancamos con el primer concepto. Aquel trabajo que es relativamente conocido y conocible (pero que tampoco es obvio) vamos a llamarlo complicado. Lo complicado se puede entender desmenuzándolo en partes, aunque sean unas cuantas. Reduccionismo que funciona. El trabajo complicado se resuelve a plena deducción, siguiendo reglas lógicas y repetibles. Las mejores decisiones en esta parte del mundo son objetivas. El error, claro está, es evitable. Si nos equivocamos, significa que estudiamos poco, no prestamos atención o directamente no éramos la persona correcta. Trabajando mejor la próxima no habrá equivocación. Una máquina es complicada. El sistema ferroviario es complicado. El otro espacio, el más allá, queda casi casi llegando al caos. Lo llamamos parecido, pero distinto. Lo llamamos complejidad y va a ser el escenario de buena parte de este libro. Lo complejo está compuesto de partes que relacionadas son, sino más, al menos distintas que su mera suma. Por eso decimos que lo complejo solamente puede entenderse (y tampoco demasiado) mediante una mirada sistémica. Los problemas complejos se encaran mediante experimentos, no deducción. No usamos algoritmos, sino meras heurísticas. Las mejores decisiones, si bien informadas, son en esencia subjetivas. El error por ende es inevitable y fuente de aprendizaje. Un organismo es complejo. El tránsito es complejo. Y ahora, el momento de las preguntas: ¿La gente es complicada o compleja? ¿Y si mucha gente quiere organizarse? ¿El mundo del trabajo está más pensado en términos mecánicos u orgánicos? ¿Qué pasa si tratamos de resolver un problema complejo como si fuera complicado? ¿Los problemas complicados serán siempre automatizables? ¿Las jerarquías y la especialización tienen más que ver con lo mecánico o con lo orgánico?
Solemos pensar la metáfora como un mero recurso literario que permite salpicar unas gotas de lirismo en un texto demasiado soso. Lakoff y Johnson no están de acuerdo y yo les creo. Hace ya varios años escribieron un libro brillante llamado Metáforas de la vida cotidiana, en el que argumentan que nuestro modelo de conceptualización del mundo es esencialmente metafórico. La metáfora nos permitiría entender un mundo en esencia inabordable por nuestros sentidos, guiando en definitiva nuestro comportamiento. Lakoff y Johnson argumentan que en un mundo tan complejo, solamente comprensible por medio de metáforas, no existe la objetividad (de hecho plantean que la propia idea de objetividad puede ser social y políticamente peligrosa). Esto no implica que todo hecho sea absolutamente subjetivo, sino que proponen la metáfora compartida como eje cultural que permite compartir una noción de verdad. Tal vez el principal mensaje que quiero transmitir en este libro sea que hoy en día vemos el mundo laboral mayormente mediante el prisma de la metáfora mecánica y eso nos limita. Esto implica que, si no reflexionamos en ese sentido, vamos a incorporar nuevos métodos de trabajo (entre ellos scrum), manteniendo la metáfora y con ella sus vicios. Propongo en voz alta que scrum alcanza su potencial solamente desde una mirada orgánica. Pero antes de seguir gritando verdades al viento, analicemos, pensemos, reflexionemos.
Sí, la imagen de Chaplin ajustando engranajes puede parecer exagerada, pero en el fondo el trabajo de hoy en día no se organiza de maneras muy distintas. Nacida al calor de la revolución industrial y el iluminismo, la metáfora mecánica del mundo del trabajo se viene manteniendo casi incólumne desde entonces. Pero antes de ponerla en duda tratemos de resumir esta mirada. Por un lado tenemos la división del trabajo, ya desmenuzada por Adam Smith en su fábrica de alfileres, que busca generar eficiencia en la producción. El procedimiento es simple: un trabajo o proceso se analiza como secuencia, que luego se particiona y asigna a distintas personas (y eventualmente grupos, áreas o departamentos). Unos estiran el alambre, otros lo enderezan y así sigue. Cada uno se enfoca en una tarea obvia o incluso complicada, repetitiva, muy limitada, lo que permite aumentar sideralmente su productividad. Por otro lado se establece la estructura de poder jerárquica, que produce una gran eficiencia en la toma de decisiones. Esto es, si se necesita tomar pocas decisiones, una estructura jerárquica elegirá su camino en un abrir y cerrar de ojos. Esta estructura se compone en todos menos su último nivel de un invento de la modernidad llamado management. El management propone dividir el pensar del hacer. Mientras el último nivel de la jerarquía hace (un hacer que hoy en día implica también pensar), los managers se concentran en pensar y decidir sobre organización de personas y estrategia. El trabajador de la base de la pirámide puede olvidarse por completo de ambos temas y concentrarse en hacer, hacer mucho. La jerarquía se acopla a la perfección con la división del trabajo. En el caso de los alfileres de Adam Smith, esto significa que todos los estiradores de alambre tendrán un supervisor, que tomará las decisiones más relevantes sobre cómo se debe estirar el alambre y cómo se debe evaluar a los estiradores. Siguiendo la misma lógica, cuando crezca la producción y por ende el volumen de personas, se creará la figura del supervisor de supervisores. Bienvenidos al management, bienvenidos a la máquina. Un problema complicado es, dijimos antes, controlable. Si no logramos controlarlo, nos falta de pericia. Dicho de otra manera, la imposibilidad de controlar el trabajo estaría exponiendo un error evitable de nuestra parte. La tercer pata del enfoque mecánico es entonces la planificación, origen del ubicuo mantra autoflagelatorio conocido como "faltó planificación". En una humilde teorización, podemos resumir entonces que el paradigma mecánico propone en esencia división del trabajo, jerarquía de poder y planificación.
Tal vez no sea bueno generalizar. Tal vez en su momento la realidad fue más comprensible y hoy, producto de la aceleración geométrica del cambio, la norma sea la incomprensión de la realidad. Es cierto que otros han utilizado la metáfora orgánica para pensar las organizaciones. Con humildad entonces, sin ánimo de realizar grandes postulados ni revoluciones científicas, veamos por un momento el mundo del trabajo con una mirada orgánica. La analogía, como todas, tiene múltiples perspectivas. Arranquemos por una. ¿Qué pasaría si pensáramos que las organizaciones están vivas, que tienen un cuerpo? ¿Qué pasaría si obligáramos a ese cuerpo a moverse contra su naturaleza? ¿Y si lo forzáramos a estar quieto? Algo, como mínimo, le dolería. Veamos, escuchemos, sintamos esos dolores. Y de paso, entendamos scrum.
Volvamos al comienzo. Volvamos al principio del principio. Preguntémonos, tal vez por primera vez en mucho tiempo, para qué hacemos lo que hacemos. El gran Jeff Patton dice, con la suficiente grandilocuencia, que el trabajo de los desarrolladores de software no es, justamente, hacer software. Su trabajo, dice Patton, es cambiar el mundo. Indaguemos. Parafraseando al amigo con nombre de general aliado, hacemos lo que hacemos porque alguien ahí afuera está triste, necesita algo, podría estar mejor. 
Nuestro trabajo sería, visto desde esta óptica, transformar la mayor cantidad de caritas tristes en caritas felices. Es importante en este punto recordar (¿admitir?) que no siempre llegaremos a tiempo a convertir todos los ceños fruncidos en sonrisas. Tal vez más importante (¿doloroso?) sería entender que muchas veces, en nuestro intento de producir sonrisas, lo que generamos es aún más tristeza. Llanto, por qué no. 
El ratio de caritas felices sobre tristes lo definiremos como outcome o impacto de nuestro trabajo. El outcome, humano hasta la médula, vive en el mundo de la complejidad y por ende será siempre subjetivo. Hagamos lo antes posible el duelo de toda ilusión de completa objetividad a la hora de convertirlo en un dato numérico obtenido de forma directa. Una vez transitado el duelo, concreticemos. Para generar outcome tenemos, si todo va bien, ideas. Lo que solemos llamar "trabajo" consiste básicamente en convertir estas ideas en un producto o resultado concreto. El producto puede o no ser tangible. El producto puede ser una silla, un sitio web, un asesoramiento legal o todo eso junto. Al producto vamos a llamarlo output, compañero inseparable del outcome. El output, claro está, pertenece a la esfera de lo complicado y por ende es directamente mensurable. Diez sillas en dos horas es output. Al outcome, en cambio, siempre llegamos de maneras indirectas, por medio de representaciones. La rentabilidad (en las organizaciones con fines de lucro) podría ser un buen indicador, siempre indirecto, del outcome. También lo sería una encuesta de satisfacción de usuarios o un índice de conversión. Preguntémonos en voz alta antes de esbozar una respuesta por escrito: ¿Qué relación debería haber entre output y outcome? ¿Cuál suele haber en realidad? ¿Evoluciona esta relación?
Recordemos que, desde la tradicional mirada mecánica, el mundo es comprensible si usamos la técnica correcta. Este es justamente el supuesto que nos hace pensar que planificar es una gran idea. Pero mejor volvamos al dolor que nos convoca. Muchas veces, demasiadas tal vez, el output alcanzado no genera el outcome que esperábamos. Fabricamos la silla con las características, tiempos y costo esperados (output), pero el cliente dice que no está satisfecho (outcome). Claro, lo más sencillo es tildarlo de caprichoso y esperar, sin muchos argumentos, que el próximo sea más coherente. Tal vez, solo tal vez, el problema está en otro lado. Tal vez el uso, la interacción de un humano (paradigma de lo complejo) con un producto complicado configure un problema complejo en si mismo. O sea, un auto es complicado. Manejarlo es complejo. Una silla es complicada (obvia diría alguno). Que me guste, sea cómoda, la disfrute, es complejo. Las personas vendríamos a ser algo así como Reyes Midas de la complejidad, capaces de convertir lo que tocamos en complejo. Sigamos el razonamiento. Si diseñar productos para humanos es una actividad compleja, entonces tal vez un enfoque orgánico dé mejores resultados. Entendamos qué sería encarar el diseño tanto de forma orgánica como mecánica.
Un árbol, una planta, siempre sirven para ejemplificar la mirada orgánica. Preguntémonos, aunque más no sea sumando una buena dósis de imaginación, cómo se podría "construir" de manera mecánica. El primer paso ineludible será diseñar "en papel". De alguna manera intangible describimos el producto final. 
Después procedemos a la división del trabajo, a la modularización. Un especialista (o grupo especializado) se encarga de construir las raíces, otro el tronco y un tercero la copa. Un cuarto especialista, por ahora en espera (o muy probablemente abocado a otro proyecto), será responsable de integrar estas tres partes cuando ya estén listas. Por último, un quinto especialista será el responsable de instalar el árbol integrado en el terreno.
Este proceso, motivado casi exclusivamente por la búsqueda de eficiencia, parte de una hipótesis que no hay que olvidar: la relación entre output y outcome es complicada. Dicho de otra manera, es posible pensar a priori, intelectualmente, de forma abstracta, en el tablero, un producto (output) que vaya a tener un impacto dado (outcome). Si en realidad hubiera que aprender (confirmar) qué es lo que realmente quiere o necesita el usuario, entonces podríamos pensar que prácticamente todo ese aprendizaje se da recién al final de todo este proceso. 
Como vimos antes, aprender es muy caro en el enfoque mecánico. Por el contrario, un enfoque orgánico debería tender a maximizar ese aprendizaje. Es decir, vamos a intentar aprender mucho y rápido.
Si aplicamos nuestro conocimiento, un poco rudimentario, de agronomía y biología, arrancamos este proyecto con una semilla. Esa semilla permite soñar con un árbol de ciertas características. Otros han plantado semillas similares en terrenos similares y han obtenido, con ciertos cuidados y un poco de buena suerte, un árbol como el que queremos y necesitamos. Esa semilla la plantamos en el terreno en el que queremos que crezca el árbol. Y he aquí la primer diferencia fundamental con el enfoque mecánico: empezamos en el terreno real, con el objetivo de maximizar el aprendizaje. Probamos nuestro producto con un usuario real en una situación real. Si todo va bien, regando, cuidando el terreno y con un poco de paciencia, sale un brote. Analicemos ese brotecito, porque en él está la esencia del cambio de enfoque. El brote es, desde un punto de vista de diseño de producto, un árbol. Tiene todas las funcionalidades que definen a un árbol: raíces que toman nutrientes y agua del terreno, un tronco que le da sostén y hojas con clorofila que le permiten hacer fotosíntesis. 
A diferencia del enfoque mecánico, en este caso no tenemos la mente puesta en maximizar eficiencia, sino más bien en aprender. Pensamos, básicamente, que no sabremos nunca qué necesita nuestro usuario si no probamos y nos equivocamos. Invirtiendo relativamente poco tiempo y orgullo, ya tenemos retroalimentación de un usuario real en un terreno real. Reaccionamos adaptando el producto a partir de lo aprendido. La equivocación es, ante todo, información.
Scrum en esencia propone ciclos cortos de producción y aprendizaje. Al final de cada ciclo deberíamos tener un incremento de producto (output), para así poder pedir retroalimentación de nuestros usuarios (outcome). Scrum, en el fondo, nos está empujando a diseñar de forma orgánica. El secreto tal vez sea no resistirse.
¿Cómo diseñamos hoy en día? ¿Cuánto tardamos en aprender con ese enfoque? ¿Nos resultará útil aplicar un enfoque más orgánico? ¿Cómo nos lo imaginamos? ¿Cuáles serían los principales desafíos?
El pecado original del enfoque mecánico frente a problemas complejos es siempre el mismo: falta de humildad intelectual. Enfrentados a un problema, en este caso construir un producto técnicamente correcto, subestimamos su complejidad (o sobreestimamos nuestra capacidad intelectual). Asumimos que somos capaces, por nuestra experiencia y educación, de comprender el problema y diseñar una solución eminentemente correcta. Esta arrogancia intelectual suele salir a flote, aunque cueste admitirla, sobre todo cuando tratamos de integrar los distintos módulos en los que dividimos la construcción. Recordemos que dividimos para maximizar eficiencia, no aprendizaje.
A esta altura ya parece un estribillo, aunque en este caso suene más bien a oxímoron: la propuesta es la construcción orgánica. Retomemos el ejemplo del brote. Plantamos una semilla en el terreno y crece un primer brote. Desgranemos la metáfora en este caso. El terreno representa nuestra infraestructura o contexto técnico real (o al menos realista). El verdadero terreno en el que vamos a construir e integrar. Las raíces, el tronco y las hojas representan las distintas partes internas que componen el producto. En el caso del software, por ejemplo, hablaríamos aquí de arquitectura.
Hasta ahora vimos que crecer orgánicamente significa rápidamente tener un incremento holístico en circunstancias reales (o realistas). Pero hay más. Lo orgánico es perecedero (impermanente dirían los budistas). Una planta que se descuida puede secarse o enfermarse. El jardinero fiel debe preocuparse no solamente por la nueva rama, sino por todas las anteriores. Llevado a nuestra realidad, esto implica que crecer orgánicamente implica mantener la calidad permanentemente. Pero la calidad se ve en jaque permanentemente por la constante evolución interna del producto. En el caso del software esto nos lleva a tener sí o sí pruebas automatizadas que corran continuamente (que a su vez permitan el refactoring continuo) si queremos desarrollar orgánicamente. Pero eso es, aunque intrigante, otra historia, que tal vez después retomemos.
¿Cuán maleable es mi material de trabajo? Dicho de otra manera, ¿Cuánto me cuesta cambiar lo ya hecho? ¿Habrá otras maneras de hacer lo que hago que permitan un menor costo de cambio? ¿Realmente necesito transicionar hacia una manera más orgánica de construir? ¿Cuán seguido me sucede que lo construido no funciona o no se integra como lo había planeado? ¿Cuántas veces me escucho diciendo que "la próxima vez lo vamos a planificar/diseñar/definir mejor"?
Este dolor tal vez sea el más intuitivo de todos. Pero antes que nada una aclaración importante sobre el término proceso. Cuando lo usemos no vamos a estar hablando, necesariamente, de un conjunto de reglas escritas. Vamos a definir proceso como la manera en la que trabajamos. Esa manera puede o no estar escrita, explicitada o incluso entendida por todos. Si todos los días nos sentamos en la misma silla, eso es proceso. Si usamos chistes y tomamos todas nuestras decisiones por consenso, vamos a llamarlo también proceso. Cada vez que definimos proceso, de formas más o menos explícitas, hacemos un diagnóstico de la realidad que nos rodea. "Ya no vengamos a la oficina porque se pierde tiempo". "Empecemos a venir a la oficina porque por teléfono perdemos calidez". El dolor en este caso es el proceso que, una vez definido, se ha mantenido estable (¿anquilosado?) durante demasiado tiempo. Las circunstancias cambian, pero el diagnóstico no se renueva.
La causa de este dolor vuelve a ser, en el fondo, la misma de siempre. Dijimos, como hipótesis al menos, que el hombre es el Rey Midas de la complejidad. Todo lo que toca se vuelve complejo. De esta definición sería bastante trivial concluir que el proceso de trabajo de un grupo de personas es siempre complejo. Y sin embargo muchas organizaciones (¿casi todas?) tratan al proceso de trabajo con un enfoque eminentemente mecanicista. Al fin y al cabo el término Recursos Humanos no convoca imágenes de pastizales y huertos, ¿no?
No solamente. Pero nos estamos adelantando. Por más que suene demasiado esperable a esta altura, explicitemos. La propuesta en scrum, al menos en la interpretación del framework que estamos esbozando en este libro, será que tengamos una mirada orgánica del proceso. Esto implica que el proceso comenzará pequeño, con sus elementos mínimos, para después ir creciendo de a poco. No olvidemos que orgánico incluye también un crecimiento en el terreno. En términos de proceso esto implica que nadie define la manera de trabajo de antemano desde fuera, sino que será decidida in situ, por los propios implicados.
Para contestar vayamos lejos, muy lejos, hasta Aristóteles, que nos ofrece un modelo más para entender la complejidad. En primer término un problema tiene una complejidad esencial. Esta complejidad es inherente al problema. Es irrompible, nadie ni nada podrán jamás simplificarlo. A ver, vamos con una anécdota para tratar de tomar el concepto por las astas. En la Patagonia Sur, al sur del sur de la Argentina, que queda muy al sur, hay una serie de pequeñas cadenas montañosas hechas de granito entre medio de los Andes. El granito, como todos sabemos, es muy duro. Entre estas montañas de granito se encuentra el Cerro Torre. Muy poco vistoso pero bastante vertical, es considerado por muchos como uno de los mayores desafíos que puede llegar a enfrentar un alpinista. El Cerro Torre no solamente está compuesto de granito, sino que además es prácticamente vertical y se ve azotado de forma casi permanente por fuertes vientos. En 1959 un italiano llamado Maestri subió con un colega austríaco pero bajó solo: el pobre amigo teutón había fallecido en el camino. Maestri contó al mundo, champaña en mano, que había llegado a la cima. Pero, oh fortuna injusta eres, el austríaco llevaba la cámara de fotos y una avalancha se los había llevado a ambos al averno. Dudas, suspicacias, años de orgullo herido y Maestri, harto de tanto comentario cizañero, decidió hacia 1970 mostrarle al mundo que quien escala el Cerro Torre una vez, lo hace dos. Esta vez no iban a quedar dudas. Ni una sola. Maestri emprendió camino junto a una verdadera troupe que pudiera no solo comprobar sus hazañas sino sobre todo llevar el taladro neumático, con su correspondiente compresor, con el que terminó agujereando la temible pared de granito que lleva a la cima ¿Cómo logró Maestri llegar a la cima? No llegó en helicóptero, pero casi. Cambió el juego: dejó de hacer alpinismo y se puso el casco de ingeniero civil. O, puesto en términos aristotélicos, disminuyó la complejidad esencial de un problema, ¡cambiando el problema! Tentación en la cual caemos muchos trabajadores del conocimiento cuando nos damos cuenta de que somos incapaces de resolver un problema que se nos plantea. La omnipotencia intelectual nos traiciona de a ratos y nos vuelve un poco Maestri.
¿La lección? Scrum podrá ser maravilloso o podrá no serlo, pero seguro no resuelve el problema en si ¿Para qué sirve scrum entonces? ¿Qué relación tiene con el proceso? Sigamos con Aristóteles, que siempre suena elegante citarlo. Como se ve en el dibujo, siempre que nos enfrentemos a un problema deberemos lidiar no solamente con la complejidad esencial, sino también con la complejidad accidental. 
Esa complejidad no es propia del problema, sino que viene de regalo. En la filosofía de gestión Lean, de la cual no importa si has escuchado antes o no, se habla del desperdicio o esfuerzo que no aporta para resolver el problema en si mismo. Lean significa "magro": con poco o nada de grasa. Pensemos entonces que todo lo que hacemos para resolver la complejidad esencial es músculo y todo aquello que no hace más que incrmentar la complejidad accidental apenas grasa acumulada. Hay grasa cuando no confiamos en nuestro jefe ni él en nosotros. Hay grasa si la silla es incómoda y el baño de la oficina huele mal. Hay grasa siempre que estemos agregando complejidad innecesaria.
Scrum promete ayudarnos a detectar la capa de grasa más voluminosa y enfrentarnos cara a cara con ella. Scrum es una simple gimnasia que hace que emerjan las disfuncionalidades organizacionales ¿Cómo se resuelven estas disfuncionalidades? Hay tantas respuestas como situaciones. Scrum no se inmiscuye: es solamente el mensajero de la malas nuevas. Matarlo o escucharlo es decisión de quien lo utiliza.
¿Cada cuánto reflexionamos sobre nuestro proceso? ¿Quiénes lo hacen dentro de la organización? ¿Se considera trabajo cuando utilizamos tiempo en reflexionar? ¿Habrá sido siempre así en la historia del trabajo? ¿Quién se supone que debe reflexionar en una línea de producción tradicional? ¿Qué convendrá hacer en nuestro caso particular?
La división del trabajo es, como toda idea poderosa, una espada de doble filo. El propio Adam Smith, a quien ya encontramos admirando el aumento de productividad consecuencia de la especialización, advierte sobre los riesgos de esta práctica. El padre del capitalismo observa que el tedio propio de la especialidad deshumaniza. Evidentemente hemos priorizado las ventajas. El imperativo del crecimiento, también descrito por Smith, hizo que los individuos especialistas se transformaran en equipos especializados. De la mano de la segunda revolución industrial, los equipos se convirtieron en departamentos y así nació el silo funcional. Cientos, tal vez miles de trabajadores de la misma organización, todos enfocados en una única porción de la cadena de valor.
La confianza tiene como precondición la visibilidad y entre silos no se ve, o si ve no existe motivación para mirar fuera de la propia realidad. Entre silos la desconfianza crece como la hiedra. La confianza a su vez es precondición de la colaboración. Colaboración significa sumar esfuerzos en pos de un objetivo común. Gracioso y terrible a la vez, los silos por definición tienen objetivos distintos. Pero la situación es todavía peor. Dijimos que los sistemas complicados o mecánicos pueden entenderse mejor si se analizan sus partes por separado. Tal vez eso haya llevado a muchas organizaciones (¿casi todas?) a optimizar cada una de esas partes por separado. En concreto, los objetivos (y los premios y castigos asociados) de cada silo se contradicen entre sí (o al menos no se complementan). Un ejemplo clásico es el infausto comercial, odiado por todo el resto ¿Puede ser peor aún? ¡Claro! La fronteras entre silos, tan claras en la teoría, se difuminan frente a la complejidad real del día a día. Clásicos como "no es nuestra responsabilidad" o "hay que definir mejor los roles" pintan la situación de cuerpo entero. En resumen, como mínimo los silos generan desconfianza por falta de visibilidad, falta de colaboración por tener objetivos disjuntos (o incluso contradictorios) que surgen de optimizar localmente y roces eternos producto de responsabilidades indefectiblemente difusas. Como bien dice Larman, la cultura sigue a la estructura. Ni mil actividades de teambuilding con sogas y remos van a conseguir que los silos dejen de competir entre sí.
Los silos generan multitasking de una manera bicéfala, casi macabra. La primer causa yace en la falta de visión unificada a nivel de stakeholder. Las distintas áreas reciben permanentemente pedidos contradictorios provenientes de sectores que carecen de incentivos reales para colaborar. Esos sectores gritarán cada día más fuerte y con más inteligencia, a fin de imponer su agenda por la de sus pares. El área proveedora no podrá en principio hacer mucho más que correr a toda velocidad con varias bandejas en una mano, mientras se seca el sudor de la frente con la otra. La segunda fuente de la multitarea se produce al interior de los silos. Éstos, por definición, no son capaces de completar ninguna tarea de utilidad por sí solos, sino que fueron explícitamente diseñados para depender unos de otros. Si el flujo de pedidos entre silos fuera predecible, sería posible planificar con éxito su capacidad. Pero en la vida real el flujo de pedidos entre los trabajadores del conocimiento es prácticamente aleatorio al mediano plazo. No hace falta decir que esto produce que algunos silos estén sobrepasados y otros ociosos. Dado el carácter cuasi religioso de la productividad en el pensamiento mecánico, el ocioso se encuentra ahora en flagrante herejía. Lógicamente tomará, lo antes posible, una nueva tarea. La locura del multitasking comenzó. La mayoría de las organizaciones son como autopistas en hora pico. Si le preguntamos a cualquier conductor si la ruta es un éxito, seguramente nos responderá con una mezcla de rabia e impotencia. Increíblemente esa autopista es, desde la mirada existente en muchas organizaciones, un éxito. El foco fue puesto en maximizar utilización de los recursos y, lamentablemente para los usuarios, se logró.
Como era de esperar a esta altura, Scrum propone una estructura organizacional orgánica. Al hablar de diseño dijimos que el enfoque mecánico prioriza eficiencia, mientras que el orgánico pone por delante el aprendizaje. Ahora que hablamos de estructura, el enfoque mecánico vuelve a estar basado en la búsqueda de eficiencia a través de la especialización, mientras que el orgánico priorizará la autonomía del equipo a fin de maximizar su adaptabilidad. Scrum entonces fomentará fuertemente la autonomía, tanto en habilidades como en potestades.
Hasta ahora fuimos describiendo scrum de formas genéricas. Antes de pasar a sus reglas más concretas, que las tiene, repasemos sus pilares conceptuales. Scrum propone dos grandes cambios a nuestra forma de trabajar. La primera es la producción orgánica en vez de la mecánica, que permite priorizar el aprendizaje sobre la predictibilidad y la adaptabilidad sobre la eficiencia. La segunda es la organización alrededor de los equipos autónomos en vez de los especialistas tutelados en jerarquía. Por medio de esta autonomía buscamos ganar foco, diversidad y, nunca está demás, un poco más de humanidad.
Y ya que hablamos de humanidad, situemos a nuestro trabajo en esa dimensión. Hay gente triste. Vamos a llamarlos stakeholders. Nuestra decisión es convertir esa tristeza en alegría. O lo que es lo mismo, lograr un outcome o impacto. Pero el impacto, como ya vimos, solo puede lograrse de manera indirecta a través de su par concreto, el output. Usaremos scrum para producir un output y, lo antes posible, intentaremos comprobar, con alta subjetividad, si con eso logramos outcome.
Dijimos que este trabajo tiene mucho más de complejo que de complicado. Y también dijimos que una buena manera que conoce el hombre de lidiar con la complejidad es el foco. Decirle que no, oscurecer estímulos, para disminuir la complejidad percibida y poder hacer algo con ella. Se escucha un relámpago, siento el viento en las mejillas, tengo hambre, me duele el golpe en la rodilla y creo ver un lobo que se mueve entre los árboles. Lo único que importa ahora es el lobo. Todo lo demás desaparece y así sobrevivimos hasta ahora. Representemos este intento de foco con un embudo, en el que inicialmente ingresarán nuestras grandes y difusas ideas. No pasan, claro está, en cuanto el embudo se angosta. Debemos cortar esas ideas en ideas más pequeñas. Pero no hay una sola manera de hacerlo.
La división del trabajo es una posible manera de partir un trabajo grande en muchos trabajos pequeños. Es una división mecánica, pensada desde el proceso. Si fuéramos a preparar una torta, de una división mecánica obtendríamos etapas. Pesar la harina, batir los huevos o amasar la mezcla. La debilida de este enfoque en un contexto complejo es que recién aprenderíamos sobre el cómo (¿funciona el output?) y el qué (¿logramos outcome?) recién luego de la última etapa. Lo que llamamos división orgánica redundaría en pequeños cupcakes, al menos inicialmente. Resignamos eficiencia y predictibilidad para ganar aprendizaje y adaptabilidad. Iremos alimentando nuestro embudo de grandes ideas, subdivididas recursivamente en ideas pequeñas, valiosas por sí solas.
Al final del embudo vive el principal rol de scrum, el equipo de desarrollo, quien de forma cíclica realizará la alquimia productiva, convirtiendo ideas en incrementos orgánicos de un producto o servicio. El bendito output. El equipo de desarrollo será ante todo autónomo para poder lograr un outcome. Esto significa que deberá tener autonomía tanto en términos de habilidades como de potestad. Tiene que saber y se le tiene que permitir. Parte de esta autonomía implica que su organización interna es su entera responsabilidad. El grupo es responsable, por ejemplo, de asignar tareas entre sus miembros o incluso de decidir que el equipo debe subdividirse en dos equipos más pequeños. Se dice entonces que este grupo se autoorganiza. La autoorganización, propia de los sistemas complejos, no implica ausencia de organización (tal vez más propia del caos), sino una organización emergente. En los sistemas complicados la mejor organización surge a priori y a partir de agentes externos, como en el caso del supervisor propuesto por Taylor. En los sistemas complejos, en cambio, la organización surge continuamente y a partir de quienes componen el sistema. Para que un grupo de personas pueda autoorganizarse de forma cotidiana, cada integrante tendrá que comunicarse de forma continua con todo el resto. Nuestra cabeza, por más que nos cueste admitirlo, tiene límites. Es por eso que los grupos autoorganizados de más de 9 personas suelen subdividirse, aún de las maneras más sutiles, en grupos más pequeños. Por otro lado, dijimos que para lidiar con la complejidad vamos a priorizar la diversidad de conocimientos por sobre la extrema especialidad. Un equipo demasiado pequeño carecerá, tal vez, de la diversidad necesaria para encarar un trabajo complejo. Si hoy pertenecemos a un "equipo de 1" o incluso de 2 personas, preguntémonos si lo que hoy llamamos equipo no es más que un engranaje en una maquinaria más compleja.
Muchos equipos de desarrollo, sobre todo los que tienen poca experiencia, terminan demasiado enfocados en el output. Superados por las circunstancias, priorizan aquello más tangible y cercano. Echemos mano a un recurso obvio y facilmente abusable ¡Agreguemos un rol! Con ustedes, el Product Owner o dueño del producto. Un nombre, como tantos en scrum, no muy bien elegido. Pero es el que tenemos, así que mejor elijamos las batallas y avancemos. El Product Owner o PO tiene una única y gran responsabilidad: maximiza outcome, minimizando output. Ni más ni menos.
Recurramos de nuevo a las metáforas, tan simplistas y abusables, pero tan necesarias. El PO puede ser visto como un director de orquesta. No toca ni el violín ni el trombón, pero ante el público es claramente el gran responsable de lo que suceda durante el concierto. Por algo recibe más aplausos o abucheos que el resto, ¿no?
El Product Owner es claramente un resabio de jerarquía que vive en scrum. Carece de toda autoridad sobre el equipo. No puede decidir quién toma una tarea, ni si alguien debe salir del equipo. Su única autoridad es sobre el producto. Este resabio nos muestra que scrum no es, ni mucho menos, el destino sino apenas un camino, una transición.
Product Owner y equipo de desarrollo tienen sus ojos y su energía concentrados en una sola cosa: el producto. Y dado que no hemos dicho nada sobre cómo deben trabajar podemos afirmar que conforman un gran equipo auto-gestionado. Dado que ellos son quienes están día a día enfrentándose cara a cara con la realidad del proyecto, quién mejor para decidir el proceso que ellos mismos. Si aceptamos que el proceso que necesita un equipo para desarrollar de manera óptima un producto complejo es complejo en si mismo, no podemos quedarnos en la noción industrial (¿Se acuerdan del viejo paradigma?) en la que un supervisor decide desde fuera cómo debe trabajar el empleado. Eso está muy bien para martillar clavos, pero en el caso de un proyecto complejo, en el que no nos queda otra alternativa que apelar al lado más humano de los trabajadores, perderíamos potencial creativo y, sobre todo, compromiso con el resultado final si impusiésemos proceso.
Pero la auto-gestión no es ninguna panacea per se. Es simplemente un llamado a gritos al caos. Y ya vimos lo interesante, pero también lo riesgoso que puede ser el caos. Necesitamos límites, pero queremos que esos límites sean auto-impuestos. Traigamos a escena a una tercer figura, que actúe de espejo tanto para el equipo de desarrollo como para el Product Owner, para recordarles los límites que nos impone scrum, a fin ayudarlos de canalizar el caos y llevar a buen puerto un proyecto que necesita de altas dosis de creatividad. Traigamos a un ScrumMaster.
El ScrumMaster, además de tener un nombre grandilocuente y confuso, es una figura poco tradicional en las organizaciones. El ScrumMaster es ni más ni menos que un espejo: es responsable, desde una perspectiva de proceso, de que Product Owner y equipo de desarrollo trabajen de manera autónoma y fluida. Para ello un ScrumMaster suele llevar a cabo cuatro labores básicas:
-
Facilitador: alguien que ayuda a un grupo de personas a tomar una decisión no trivial desde un punto de vista neutral
-
Coach: un evocador de excelencia - soplador de brasas, que supieron ser fuego y necesitan ser avivadas
-
Mentor: maestro que instruye desde una posición de igualdad y procura que el mentoreado siga su propio camino lo antes posible
-
Agente de cambio: inicia, conduce y ejercita el cambio de estructuras, políticas y sentidos comunes dentro del equipo y en el contexto que lo rodea
El ScrumMaster, o simplemente SM, suele llevar una sola herramienta en su bolso: la pregunta. Puede ser insidiosa, básica, generadora de silencios incómodos, cándida, retórica. Las hay de todo tipo y color y, a diferencia de las respuestas, son ellas las que mueven al mundo.
Faltaría una metáfora, ¿no? El SM tiene como objetivo, aunque más no sea más que una utopía útil, perder su trabajo lo antes posible, convertirse en obsoleto. Como el referí, cuanto más desapercibido pase su labor, mucho mejor. O como dijo el gran Harrison Owen cuando describió al facilitador, "hacer nada con elegancia". Podemos pensar en la expresión, casi un anglicismo, "la mosca en la pared". Alguien que está, pero nadie se percata de su presencia. Pero le falta empuje. Mejor recurramos a Mafalda. Libertad, para ser más precisos, que en una tira ya legendaria nos dice que "un abejorro no puede frenar un tren, pero puede llenar de ronchas al maquinista". Ese, justamente, es el ScrumMaster que queremos. Si bien no es el conductor, gran jefe, presidente, CEO o todo eso junto, deberá molestar a quienes tienen poder hoy en día, con el fin de alertar y eventualmente lograr un cambio de dirección. O como dijo mi amigo y mentor Tobías Mayer, "un buen SM debe estar siempre al borde del despido".
La palabra "backlog" podría traducirse como "lista de lo que me falta para...". El Product Backlog será entonces la lista de características de las que carece hoy en día el producto. En él se ve plasmada la estrategia del proyecto. El responsable de tener el backlog que marque el mejor recorrido posible hacia la visión será obviamente el Product Owner. Por eso decimos que es el responsable de este artefacto. Nuevamente, esto no significa que es el Product Owner quien construirá el Product Backlog. Esto, nuevamente, dependerá del contexto. Cada vez que mencionemos a los stakeholders, usualmente querrá decir que es el Product Owner quien dialoga cara a cara con el equipo, dado que su principal atributo es el poder conjugar las distintas necesidades de todos los interesados en el proyecto en un único mensaje.
El Product Backlog es simplemente una lista de lo que llamaremos, aunque sea confuso para nosotros los hispanohablantes, PBIs: Product Backlog Items. El framework no prescribe cómo se materializan los PBIs. Alguno será lo que en software llamamos Caso de Uso, algún otro en la lista será una Historia de Usuario y unos cuantos tal vez sean meras servilletas garabateadas. El framework solamente describe dos características de los PBIs:
-
Cada vez que el equipo desarrolle un PBI el producto habrá aumentado el valor percibido por los stakeholders (crecieron raíces, tronco y rama hasta darle sombra a una persona más)
-
Los PBIs se encuentran ordenados según el criterio que decida el Product Owner. Usualmente se utiliza como criterio para esto la secuencia que maximice la relación costo/beneficie, siempre que la misma respete dependencias y considere riesgos, tanto técnicos como funcionales.
Y ahora la pregunta de rigor: ¿Para qué pide esto el framework?
El primer punto es la manera de poner en práctica el desarrollo o crecimiento orgánico del producto. Cada salto entre piedra y piedra nos acerca de manera consolidada (o no nos acerca, en caso que el equipo haya construido un PBI de manera incorrecta) a la visión. Su aceptación por parte del Product Owner será binaria: brinda valor o no lo brinda. No es un PBI un arco de la pelota o solamente una rama. Que el PBI entregue valor a los stakeholders nos asegura que se ha crecido de manera tal que nada a quedado a medias: si hemos estimado mal el proyecto quedaremos bien parados (tendremos producto para entregar - le habremos dado sombra a un número de personas) y, más importante aún, sólo así recibiremos feedback útil de los stakeholders, dado que ellos tienen la perspectiva de negocio, de valor. Un PBI incompleto es aquel batalla que aún no se ha decidido y por lo tanto sería contraproducente tomar decisiones estratégicas basadas en puras especulaciones.
El segundo punto (que los PBIs tengan un orden, una prioridad) es simplemente la manera de hacer que el crecimiento orgánico juegue a nuestro favor. En el viejo paradigma, el Ford T se hace completo o no se hace. En concreto, se hace todo lo que los stakeholders piden al comienzo del proyecto o hemos fracasamos. En Scrum, como ya lo vimos en los ejemplos de desarrollo iterativo incremental, hacemos algo bastante bueno que, según el proverbio chino, es enemigo de lo perfecto. La lógica es simple: dado que admitimos que existe la posibilidad de que no lleguemos a desarrollar todo lo prometido, construiremos aquellas características prioritarias primero, de forma de maximizar el valor entregado a los stakeholders.
Por último, nos adelantamos a la presentación del flujo completo del framework, presentando la relación existente entre el Product Backlog y el equipo. Al comienzo de cada iteración el equipo se comprometerá a entregar una porción del Backlog al final de la misma. Luego entraremos en mayor detalle en este punto, pero aprovechemos para bautizar a este subconjunto de PBIs como Backlog Comprometido o Pronóstico.
El Sprint Backlog materializa la táctica utilizada por el equipo para desarrollar PBIs durante una iteración (que en Scrum llamaremos Sprint). El equipo será obviamente el dueño, el responsable de esta herramienta. En ella se verán plasmadas las tareas que consideren necesarias para poder entregar al final del Sprint los PBIs a los que se han comprometido. Veremos en breve en qué momento del Sprint se produce este compromiso.
Llegamos al artefacto para el que, al fin y al cabo, decidimos usar Scrum: el producto. Al finalizar el Sprint el equipo presenta qué PBIs ha desarrollado, lo que brinda a los stakeholders, dado que cada PBI de manera individual hace crecer orgánicamente el producto, un resultado que a priori entrega valor.
Se dice que el incremento es orgánico porque cumple con lo que daremos en llamar el "criterio de hecho". Vamos a definir que algo está hecho cuando "nadie debe preocuparse más por eso". Por ejemplo, imaginemos una pareja que acaba de volver del trabajo. El marido decide cocinar fideos, mientras la mujer ordena la ropa. Gente muy hacendosa ellos dos. La mujer pregunta desde la habitación si la comida está lista. El marido responde que no, que en cinco minutos. Al cabo de un rato la mujer insiste y el marido, orgulloso, responde que sí, que la cena está lista. La mujer se dirige raudamente a la mesa y encuentra...papeles desordenados y un vaso medio vacío. Le pregunta al esposo qué pasa: ¡ni siquiera está hecha la mesa! El marido, sorprendido, le contesta que los fideos están listos, lo que significa que la cena está lista. Ahora resta servirlos en platos, limpiar la mesa, etc, etc. ¿Quién tiene razón? ¡Ambos! ¿Cuál es el problema? Que ambos tienen distintos criterios de hecho. ¿La consecuencia? No solamente el enojo de ambos, sino que las decisiones (minúsculas en este caso, millonarias en muchos proyectos) se tomaron según el propio criterio de hecho. Si un equipo entrega a un Product Owner un PBI hecho, a menos que ambos se hayan puesto de acuerdo en lo que eso significa, puede producir un gran problema tiempo después de la entrega.
Vamos con otro ejemplo del software, que es la disciplina en la que más se utiliza Scrum: un equipo entrega funcionalidad tras funcionalidad durante varios Sprints. Luego, por un cambio en la situación del mercado, el Product Owner comunica que hay que variar la estrategia y realizar algunos cambios sobre el software existente. El equipo explica que eso es muy riesgoso, dado que no se hicieron pruebas sobre lo ya entregado. El Product Owner tiene, digamos, palpitaciones. ¿Cómo se previene? Simplemente explicitando cuál será el criterio. ¿Quién es responsable de que esté definido de la mejor manera posible? Claramente el Product Owner, pues es el responsable de definir qué condiciones debe cumplir un PBI para entregar valor de negocio.
Explicamos hace ya varias páginas que en Scrum se desarrollan orgánicamente tanto producto como proceso, dado que se considera a priori que ambos son complejos. El mejoramiento o construcción del proceso puede ser visto con dos tipos de lentes:
-
Mitad\ del\ vaso\ lleno:\ la\ organización posee un conjunto de virtudes que pueden ser potenciadas -
~Mitad\ ~del vaso vacío: la organización posee un conjunto de problemas que pueden ser resueltos
Usualmente combinaremos ambas perspectivas, con mayor foco en los problemas. Cada ítem puede ser entonces un problema a resolver o una virtud a potenciar. En el primer caso cada Process Backlog Item será una situación, una complejidad accidental que nos impide ser más productivos, desarrollar productos con más calidad y trabajar con mayor felicidad. En el segundo caso nos enfocaremos en aspectos como ser las razonnes detrás de un aumento en la productividad, buena colaboración entre miembros del equipo o un acercamiento del Product Owner al equipo.
Para que nuestro proceso crezca de manera orgánica vamos a tratar a este backlog de la misma manera que al de producto: sus ítems suelen estar ordenados con el objetivo de maximizar la relación costo/beneficio. Esto es, emismo estará dada por el retorno de inversión de cada uno de sus ítems. En este caso la valoración es mucho más abstracta que en el producto: el valor está dado por cuánta productividad, calidad y felicidad estimamos obtener al remover el impedimento, mientras que su costo será una amalgama del costo monetario (ej: el servidor es lento, hay que comprar uno nuevo), humano (ej: la reuniones son monopolizadas siempre por la misma persona) y/o políticos (ej: convencer a un gerente que deje de dar órdenes de manera directa a los miembros del equipo). Hagamos zoom en ese círculo donde parece haber mucha acción. Entendamos la dinámica, exploremos el juego.
La dinámica de un proyecto Scrum puede resumirse a grandes rasgos como una serie de pasos o ciclos, durante las cuales se irán desarrollando orgánicamente tanto producto como proceso. Cada ciclo se asemejará a los saltos que realizó Hans para poder cruzar el río. Decido hacia dónde saltar, salto, levanto la cabeza y vuelvo a decidir: ¿estoy saltando rumbo hacia la visión o debo virar? ¿la manera de saltar ha sido la óptima o debo cambiarla (ej: pruebo saltar con ambos pies en vez de dar un paso largo)? Para poder tomar la decisión de virar y/o modificar la manera de saltar necesito información, que provendrá de la revisión de lo hecho recientemente. Antes de decidir tengo que frenar, observar, reflexionar y eventualmente aprender. La duración de los distintos ciclos de feedback representará los límites que procurarán encauzar el caos sin cercenar la creatividad. El primer equipo que usó scrum trabajó con ciclos de 1 mes. Si encaramos un trabajo mayormente complejo, podemos visualizar esta duración como el tiempo que vamos a demorar en saber que nos equivocamos. Desde ese punto de vista, es mucho más atractivo aplicar ciclos más y más cortos. Muchos equipos hoy en día utilizan ciclos de dos o incluso una semana. Si nos resulta impensable, aprovechemos la ocasión para indagar y aprender. ¿Qué hace en nuestro caso que resulte odiosa la sola idea de frenar a reflexionar sobre outcome, output y proceso una vez por semana? ¿Será la cantidad de procesos complicados que hacemos manualmente y en cuya automatización nunca invertimos? ¿Será las dependencias (legible como falta de autonomía desde la mirada de scrum) que tiene nuestro equipo con otros equipos y otras organizaciones? ¿Serán las dependencias que existen dentro de nuestro equipo debido a las especialidades? ¿O será también que no somos nada buenos llevando adelante reuniones y la sola idea de reunirnos más seguido nos da escozor? Grasa, hemos encontrado grasa. Festejemos y manos a la obra. Hay mucho que ejercitar. Y hablando de ejercicio, corresponde enunciar el nombre que utilizamos en scrum para describir el ciclo o paso. El término es sprint, otro nombre olvidable para la colección. Un sprint, anglicismo utilizado en algunos países de América Latina, también puede traducirse como pique o carrera. En fin, que al final de un sprint uno está bastante agotado y necesita parar, descansar. No tiene sentido en pensar la vida como un sprint detrás del otro. Y sin embargo, esto propone justamente scrum. La propuesta es imaginar una metáfora más realista, más humana. Visualicemos una caminata, que el sprint sea un simple paso.
La palabra backlog podría traducirse como "lista de lo que me falta para…". Como tantas en scrum, confunde, porque da a entender que es imprescindible hacerlo completo para tener éxito. Pero recordemos que en scrum el éxito no está dado por cumplir un plan, sino más bien por maximizar outcome minimizando output. El Product Backlog es un menú, no un plan. En él se ve plasmada la estrategia del proyecto. El responsable de que exista en todo momento el backlog que marque el mejor recorrido posible hacia la visión será obviamente el Product Owner. El Product Backlog es simplemente una lista de lo que llamaremos, aunque sea confuso para nosotros los hispanohablantes, PBIs: Product Backlog Items. El framework no prescribe cómo se materializan los PBIs. Alguno será lo que en software llamamos Caso de Uso, algún otro en la lista será una Historia o Relato de Usuario y unos cuantos tal vez sean meras servilletas garabateadas. El framework solamente describe dos características de los PBIs:
- Cada vez que el equipo desarrolle un PBI el producto habrá aumentado el valor percibido por los stakeholders o al menos hemos incrementado sustancialmente nuestro conocimiento
- Los PBIs se encuentran ordenados según el criterio que decida el Product Owner. Usualmente se utiliza como criterio para esto la secuencia que maximice la relación costo/beneficio, siempre que la misma respete dependencias y considere riesgos, tanto técnicos como funcionales.
Y ahora la pregunta de rigor: ¿Para qué pide esto último el framework? El primer punto es la manera de poner en práctica el desarrollo o crecimiento orgánico del producto. Cada salto entre piedra y piedra nos acerca de manera consolidada a la visión. Su aceptación por parte del Product Owner será binaria: brinda valor o no lo brinda. Que el PBI entregue valor a los stakeholders nos asegura que se ha crecido de manera tal que nada a quedado a medias: si hemos estimado mal el proyecto quedaremos bien parados (tendremos producto para entregar) y, más importante aún, sólo así recibiremos feedback útil de los stakeholders, dado que ellos tienen la perspectiva de de valor, del outcome. Un PBI incompleto es aquel batalla que aún no se ha decidido y por lo tanto sería contraproducente tomar decisiones estratégicas basadas en puras especulaciones. El segundo punto (que los PBIs tengan un orden, una prioridad) es simplemente la manera de hacer que el crecimiento orgánico juegue a nuestro favor. En el viejo paradigma, el Ford T, se hace completo o no se hace. En concreto, se hace todo lo que los stakeholders piden al comienzo del proyecto o hemos fracasamos. En scrum, como ya lo vimos al hablar de desarrollo orgánico, hacemos algo bastante bueno que, como dice el proverbio chino, es enemigo de lo perfecto. La lógica es simple: dado que admitimos que existe la posibilidad de que no lleguemos a desarrollar todo lo prometido, construiremos aquellas características prioritarias primero, de forma de maximizar el valor entregado a los stakeholders.
Las metáforas ayudan, direccionan y ofuscan, todo a la vez. La guerra, si bien violenta y cruel, es un evento profundamente transitado y estudiado por la humanidad. Algunas de nuestras metáforas más utiles provienen directamente de ese universo. Pensemos que tal vez, solamente tal vez, sea importante no olvidar la cantidad de sangre que viene incluida en una idea. Y ahora sí, a por la imagen. Apelemos a una vieja definición de táctica y estrategia: táctica es la mejor manera que encontramos de ganar una batalla y estrategia es la mejor elección de batallas que decidimos en pos de ganar la guerra. Es decir, en términos de un producto o servicio, la estrategia estará dada por qué características tendrá el producto y la táctica por cómo se desarrollarán dichas características. Podríamos incluso hacer un paralelismo entre la estrategia como pensamiento orientado al outcome y la táctica orientada al output. En scrum consideramos que ambos problemas son profundamente complejos. Por eso queremos encararlos de manera empírica, con ciclos cortos que aceleren el aprendizaje (o la equivocación, que es un poco lo mismo). El sprint consistirá entonces de un ciclo con foco en lo estratégico, poblado de pequeños ciclos más pequeños, dedicados más bien a una perspectiva táctica. O sea, un ciclo con muchos ciclos chiquitos adentro.
El ciclo de feedback estratégico será entonces el sprint. Durante el mismo el Equipo de Desarrollo procurará convertir el Backlog Comprometido en un incremento del producto que refleje los PBIs comprometidos. El Backlog Comprometido quedará sellado durante la duración del Sprint. Esto es, no se podrán agregar, quitar o modificar PBIs del Backlog Comprometido durante la iteración ¿Cuál es la idea detrás del sellado? Sencillamente poder encauzar el caos estratégico. De esto se deduce que la duración del Sprint, si bien podrá variar de iteración a iteración, no podrá variar durante la ejecución del mismo. El ciclo estratégico comenzará en la reunión de Planificación Estratégica y concluirá en el Review o Revisión, prácticamente sobre el final de la iteración.
La reunión de planificación estratégica tiene como principal objetivo que el equipo de desarrollo se comprometa a la porción del backlog más prioritaria que quepa dentro de su capacidad estimada de trabajo para este Sprint.
La Reunión de Revisión tiene lugar sobre el final del Sprint. El objetivo principal de la misma será que el Product Owner decida si acepta o rechaza cada uno de los distintos PBIs que el equipo haya desarrollado.
El ciclo de feedback táctico será mucho más corto que el estratégico: ningún plan resiste el contacto con el enemigo. En la táctica se verá reflejado el cómo: las tareas que realizará el equipo de desarrollo durante el Sprint para construir el incremento del producto correspondiente al backlog comprometido.
Inmediatamente después de la reunión de planificación estratégica el equipo de desarrollo se reunirá para elaborar su plan inicial. El objetivo aquí es lograr un primer esbozo de la serie de tareas que serán necesarias para desarrollar los PBIs comprometidos.
La táctica nunca se sella: en cualquier momento del día el equipo tiene la potestad de actualizarla. Sin embargo, existe un momento bien definido en el cual el equipo de desarrollo se reúne con el único objetivo de inspeccionar y adaptar la táctica: durante el mismo se procederá a la asignación, definición y actualización del estado de las tareas que conforman el Sprint Backlog. Esta reunión suele llamarse Daily Meeting, Scrum diario, Standup Meeting entre otras variaciones y es la única que tiene una duración máxima ya definida en el framework: solamente 15 minutos.
En Scrum partimos de una premisa fundamental: encontrar el mejor proceso posible para que un equipo auto-organizado desarrolle un producto complejo es un proyecto complejo en si mismo. Por ende en Scrum aplicaremos las mismas ideas que utilizamos para desarrollar un producto para construir el mejor proceso posible.
La retrospectiva es el corazón que le da vida a un proyecto Scrum. Es el motor que nos empuja a vivir un proyecto persiguiendo lo que podemos llamar una útopia útil: la perfección existe, es imposible de alcanzar y, sin embargo, todos los días intento estar más cerca. Tal vez en este concepto esté la principal diferencia entre Scrum y muchas otras formas de trabajo. Es importante, por ende, entender que será en la retrospectiva cuando se decidirá si hemos podido o no poner en marcha esta filosofía de trabajo. La retrospectiva es no solo la reunión más importante del framework, sino que suele ser también la más díficil.
Una mala retrospectiva nos deja parados en el viejo paradigma. Lamentablemente la retrospectiva más común es la que no se hace. Si salteamos la retrospectiva estamos diciendo en voz baja que el proceso tiene una importancia secundaria, que nuestro paradigma actual es el mejor posible.
Una buena retrospectiva consiste en inspeccionar y adaptar nuestra forma de trabajo. No bastará con llevar a cabo, por más sesudo que sea, un mero análisis de la situación actual. La retrospectiva debe ser generadora de propuestas concretas de mejora. Debe abrir y cerrar un ciclo de feedback sobre el proceso. Al comenzar la misma revisaremos los elementos del Process Backlog a los que los miembros del equipo Scrum se han comprometido y evaluaremos, entre todos, si el problema se ha eliminado o el potencial se ha multiplicado. Luego de esta revisión realizaremos la planificación del siguiente ciclo de feedback: previa priorización del Process Backlog, el equipo desglosará el Process Backlog Item en tareas que, al ser llevadas a cabo, mejorarán la forma de trabajo de alguna forma u otra.
¿Quiénes participan de la retrospectiva? Sobre el equipo de desarrollo y el ScrumMaster no hay muchas dudas, pero tal vez si las haya con el Product Owner. El mismo es por definición parte integrante del equipo Scrum y, por ende, partícipe del proceso. Sin embargo, es cierto que una buena porción de los proyectos en los que recién se comienza a utilizar Scrum el Product Owner es una figura de poder. Esto traerá dos consecuencias: su presencia inhibirá a los miembros del equipo de desarrollo y su ausencia lo coronará como gran chivo expiatorio. Recordemos aquí que Scrum es balance entre pragmatismo e idealismo. Si el equipo de desarrollo así lo decide, el Product Owner quedará excluído de las retrospectivas. Pero el ScrumMaster bien sabe que uno de sus principales objetivos a mediano plazo será trabajar con ambas partes para que el Product Owner pueda participar de esta reunión como un mero colega que, sencillamente, tiene otra perspectiva y responsabilidad en el proyecto.
Ya vimos las reglas y el por qué utilizar Scrum. Ahora adentrémonos en lo que tal vez sea lo más interesante: el resto. Comencemos por el "qué hago mañana si decido utilizarlo".
Escucho, leo y hasta tengo pesadillas con la misma pregunta: "¿Estoy haciendo Scrum o no?" En términos generales los coaches, entrenadores y viejos lobos de mar tienen una respuesta clara y concisa: "Si sigues todas las reglas del framework la respuesta es 'sí'. Si no, lo siento pero será un rotundo 'no'". La lógica detrás de este razonamiento tiene mucho sentido: Scrum es una pequeño pero poderoso motorcito que no alcanzará su objetivo si lo customizamos.
A partir de esta definición harto simple, Eric Gunnerson acuñó hace ya años en su blog una palabra que resume la malas implementaciones de Scrum: ScrumBut (ScrumPero).
"Sí, claro, estamos haciendo Scrum, pero tenemos tres Product Owners"
"¡Por supuesto que estamos usando Scrum! Eso sí, los sprints varían entre una semana y tres meses, según lo decida el Product Owner"
"¡Esto de hacer Scrum es genial! Es una verdadera lástima que los daily meetings duren casi una hora"
Etc, etc, etc
Siguiendo con esta línea de pensamiento existe una clara forma de comenzar tu camino con Scrum: sigue todas las reglas desde el primer día sin cuestionarlas. El motorcito va a hacer su trabajo, iluminando el camino que tenemos por delante. Sin motor no hay luz.
Scrum es una excelente manera de tratar con una organización disfuncional, pero no tiene sentido plantearse como escenario de trabajo a una organización que no funciona en absoluto. Al comenzar su utilización de Scrum las compañías tienen un cierto modo de trabajo que, mal que mal, funciona. Si no, claramente no habría organización. ¿Cómo hacemos entonces para utilizar Scrum sin despreciar ni desperdiciar un proceso que, aunque sea a duras penas, entrega resultados? Los cambios radicales raramente funcionan: las dietas son un excelente ejemplo. De gordo a flaco a gordo en, digamos, semanas. Tal vez poner en duda el enfoque del ScrumPero sirva de algo...
En lugar de considerar que estamos en un terreno absolutamente oscuro, imaginemos un cuadro distinto: si bien el status quo no puede ser descrito en términos de un cielo despejado y colinas alfombradas de césped, no estamos completamente a ciegas. Imaginemos una escena montañosa, gris, nublada. Deprimente pero transitable ¿Qué significa Scrum dentro de esta topografía apocalíptica? Un hermoso y brillante arco iris. Al final del arco iris, por supuesto, se encuentra el caldero repleto de monedas de oro. Nunca nadie ha llegado ni llegará al caldero, pero este arco iris es muy especial: acaba de ser pintado y todavía gotea monedas doradas. Existe un camino repleto de oro. Repleto. Eso sí, el sendero no está ni marcado ni es sencillo. Cuestas que trepar, desfiladeros riesgosos y precipicios que saltar. Scrum es, ni más ni menos, tu brújula. El norte es, claro está, el final del arco iris. Nunca llegarás al final pero sabes que vale la pena caminar. Eso sí, será una ardua caminata. Impedimentos. Muchos, muchos impedimentos.
Tu adopción de Scrum es un viaje único, irrepetible. Si la vemos como proyecto es sin dudas uno enormemente complejo. El enfoque que tomaremos copiará a la naturaleza: crecimiento orgánico. Nuevamente plantaremos y cuidaremos de un árbol, nuestro árbol de Scrum. El ScrumMaster (coach Scrum o como querramos llarmarlo) es la semilla de este árbol y las retrospectivas serán el agua y el sol. El terreno en el que este árbol crecerá es único, distinto de cualquier otro, irrepetible. ¿Con solamente tener un coach y hacer retrospectivas estoy haciendo Scrum? Yo creo que sí. En mi opinión Scrum no es lo mismo que el framework Scrum. Scrum es el árbol y hay árbol en cuanto haya un brote que ve la luz del sol.
¿Cómo se verán sus primeras raíces, ramas y hojas? Recordemos en qué consiste una retrospectiva: el ScrumMaster, actuando como facilitador de la reunión, ayuda al equipo para que reconozca sus dolores más agudos. La gran mayoría de esos dolores han estado allí por tanto tiempo que ya nadie los recuerde. La inercia es como la anestesia: la mente nos permite sobrevivir simplemente negando la realidad.
El equipo ha aceptado, en voz alta, que tiene problemas. Graves. Los síntomas emergieron. Ahora es momento de llegar a la causa raíz. A la enfermedad. Como lo haría un médico clínico, el coach ayuda al equipo, preguntando con el fin de generar un diálogo exploratorio, a que ellos mismos lleguen al problema que causa el dolor. Una vez que alguien admite tener un problema su perspectiva del mismo cambia indefectiblemente. Este es el momento justo para cambiar el proceso: el equipo está sediento de curas. Está listo para probar lo que el médico recomiende. Sobre todo si la propuesta no solo parece tener sentido, sino que tampoco representa tomar un gran riesgo.
Supongamos que un equipo ha estado trabajando en un proyecto durante meses. Tal vez trabajan en una consultora. Tal vez es un equipo pequeño. Tal vez su jefe es comprensivo o despótico. Tal vez tengan un sueldo altísimo. No importa el escenario: existen dolores. Tal vez el dolor más agudo hoy es la ambigüedad y contradicciones que poseen los requerimientos. La causa parece ser que el equipo actúa en respuesta al grito más histérico que reciban desde el exterior, sea del gerente de marketing o del auditor externo. El problema está sobre la mesa y el coach propone un pequeñísimo cambio en el proceso: "Un miembro del equipo intentará convertirse en el único punto de entrada para cualquier nuevo requerimiento". Probemos esto durante dos semanas. Si no funciona descartamos la propuesta, al menos por ahora. La nueva estrategia está bien clara y ha sido abrazada por el equipo. Lo intentarán por unas semanas y seguramente funcionará. La plantita de Scrum ha crecido un poco: ahora posee raíces, hojas y un tronquito que posee una pequeñísima porción del framework llamada Product Owner.
Luego de dos semanas el equipo vuelve a reunirse con el coach. La propuesta funcionó. Las cosas están un poco, solamente un poco, mejor que antes. No fue sencillo: varios stakeholders montaron en cólera al escuchar una pregunta en vez de un "sí". Pero funcionó. Ahora es tiempo de reflexionar, explorar, diagnosticar. Otra vez. El dolor más agudo es ahora que algunas tareas nunca se hacen porque todos creen que alguien ya las hizo. En la raíz del dolor hay un problema de comunicación. El coach propone: "juntarse durante 10 minutos dos veces a la semana, con el objetivo de enterarse qué están haciendo el resto de los integrantes del equipo". Suena razonable. Lo prueban y funciona. El árbol sigue creciendo. Esta pequeña rama ahora tiene una reunión que se parece, solamente un poco, a algo llamado Daily Meeting, que forma parte del framework Scrum. Y el árbol seguirá creciendo, siempre y cuando el coach siga regando la planta.
El árbol crece como resultado de la paulatina facilitación llevada a cabo por el coach. Semana a semana el facilitador ayuda a que el equipo responda una pregunta simple: qué cambiar y por qué. A este proceso lo llamamos facilitación guiada por el dolor (PDF: Pain-driven facilitation). El dolor no es infligido sino detectado y expuesto a la luz. De eso se trata Scrum al fin y al cabo.
¿Y qué hacemos entonces con el dedo acusador del ScrumPero? Si frenamos para reconsiderar a cada implementación de Scrum como un proyecto complejísimo en si mismo, la política de utilizar el framework desde el día cero es equivalente a transplantar un arbolito del invernadero de Scrum a nuestra realidad. Transplantar a veces funciona...y a veces simplemente no. Y cuando no funciona, el joven árbol parece florecer durante cierto tiempo mientras por dentro no hace más que resecarse. El árbol muere. Lentamente. Y cuando un árbol muere sólo queda la corteza, o lo que es lo mismo en este caso, las ceremonias que forman la mecánica del framework. Roles y reuniones, simples nombres sin sentido. Hasta que un día sopla un fuerte viento y el árbol cae. Tal vez porque las métricas a fin de año muestran una baja en la productividad, tal vez porque alguien se harta por fin de tener reuniones diarias de horas y horas. Se abandona Scrum. Fue una decepción más. Oportunidad perdida.