84799747 El Espiritu de Scrum

8/2/2019 84799747 El Espiritu de Scrum

1/38

El espritu de ScrumEl arte de amar los lunes

Alan Cyment, CST

v0.1


2/38

......................................................................................................................................Mi objetivo 4

.........................................................................................................................Por qu una visin 4

...........................................................................................................................La visin y Scrum 5

.................................................................................................................La visin para este libro 6

............................................................Ese maldito martillo 6

.........................................................................................Trabajadores del conocimiento: tu y yo 7

..........................................................................................................................Martillando clavos 7

.............................................................................................................................Todo es relativo 9

...............................................................................................Por qu deberas amar los lmites 10

....................................................................................................................Scrum no hace nada 11

..................................................................................................Simplemente planta una semilla 13

.........................................................Las reglas del juego 18

..........................................................................................Mi proceso, tu proceso, cul proceso 18

..............................................................................................Tan simple como un paso a la vez 19

...........................................................................................................................................Quin 20

..............................................................................................................................................Qu 23

...........................................................................................................................................Cmo 27

...............................................Brjulas, rboles y dolores 29

............................................................................................................................Tantos peros 29

....................................................................................................................El arcoiris que gotea 30

...................................................................................Sintete orgulloso de ese brote de Scrum 31

............................................................................................................El desafo del transplante 32

.........................................Esa nebulosa llamada espritu 33

...........................................................................................................De leyes y libros de arena 33

...........................................................................................Pregunta, prueba, pregunta, prueba 33

.........................................................................De que hablamos cuando hablamos de espritu 34


3/38

............................................................................................................................................Savia 35

....................................................................................................La lista, la nube, los nutrientes 35

............................................................................................................................Getting Started 38

..................................................................Chapter Name 39.......................................................................................................................................Heading 39


4/38

MI OBJETIVOEste libro surge de una necesidad concreta: mi principal actividad hoy en da

consiste en dictar cursos introductorios a Scrum. Dado que no utilizo slides ninada similar durante la clase, surgio la necesidad de poder entregar a los

alumnos un texto que resuma la ideas transmitidas y compartidas durante lacapacitacin. A este curso asisten, entre otros, profesionales con aos de Scrumsobre sus espaldas. Curiosamente muchos de ellos salen sorprendidos delcurso: acaban de entender Scrum. Estaban haciendo otra cosa. Estabanhaciendo lo mismo de siempre.

Este texto tiene un claro objetivo: describir Scrum. Tan simple, pero tan difcil.Tan til, pero tan bastardeado. Tan desconocido fuera del software. Tantopotencial desperdiciado. Y la razn es una: Scrum representa un nuevo

paradigma, una nueva forma de entender el mundo del trabajo. Y cambiarnuestros modelos mentales es, digamos, al menos incmodo.

POR QU UNA VISIN[Hans saltando entre piedras]

Frida y Hans vivan su tierna adolescencia en un buclico pueblito bvaro acomienzos del siglo XX. Se haban criado juntos, corriendo por las praderas ycazando liebres en el bosque. Hasta que las hormonas comenzaron a bullir.

Frida comenz a ver a Hans con un cario distinto, novedoso. Hans comenz aver a Frida con un cario distinto, novedoso. Estaban enamorados. Nervios yms nervios, hasta que un da Hans llev a Frida a un oscuro rincn delmercado del pueblo, le rob un beso y declar su amor eterno. Frida respondientre lgrimas que el amor de Hans era correspondido.

Pero los amantes saban que algo se interpondra entre ellos: sus familias.Campesinos ellos, apostaban a lograr un buen matrimonio para sus hijos. Unescaloncito ms en la escala social al menos, pensaban sus padres. Hans lo

medit sesudamente y finalmente anunci en un alemn seco pero firme:Nuestro amor es imposible, hermosa ma. Hans, cario, dijo Frida, hay unaposibilidad: que nuestro amor sea secreto. Vendrs todas las noches a visitarmea casa de mis padres. Hasta que un da el destino sabr cmo seguir. Estanoche, amor mo, esta noche vendrs a casa de mis padres.


5/38

Hans, emocionado, se visti esa noche con sus ropas ms elegantes y sedirigi rumbo a la casa de los padres de Frida. De pronto lo sorprendi laangustia: entre su casa y la de Frida corra un caudaloso arroyo y l nunca, entantos aos, lo haba cruzado de noche. El arroyo, transparente y con lecho de

piedras, se vea amenazante a esas horas. Y lo peor de la situacin: en Bavierade noche hay nieblamucha niebla.

Hans acostumbr su vista a la oscuridad y comprob que algo podavislumbrar: alguna que otra piedra poda divisarse delante suyo. Eligi entoncessu primer salto: esa piedra enorme y bien firme. Imposible trastabillar. Avanz ypudo ver sus nuevas opciones: momento de tomar un gran riesgo y saltar hastaese grupito de guijarros de un gran salto. Lo logr y, feliz por la velocidad de suavance, sigui y sigui, hasta escuchar el arrullo del agua sobre la orilla. Ramas

que se quiebran, pasos, respiracin entrecortada

mi amada est cerca! pensemocionado Hans. Vislumbr una sombra que se acercaba a pasosagigantados, la tom con pasin y comenz a besarla. Curioso, no recordabaque Frida tuviera tanta barba.... El suegro! El suegro! Insultos, ballestas,piedras. Hans volvi sobre sus pasos como pudo, tragando menos agua queorgullo.

Al da siguiente Frida lo llam subrepticiamente en el mercado. Se cubra conuna capa, no queriendo llamar la atencin de habitante alguno. Frida ma, lo

nuestro es imposible, murmur Hans. Frida lo calm: Mi Hans, escucha, estanoche no fallars. Pondr una vela en mi ventana y llegars a destino. Pero lavela no ilumina mi camino!, se quej Hans. No, amor mo, lo nico que tienesque hacer es, antes de dar un salto, levantar la vista y elegir, de las opcionesque tengas frente a ti, la que ms te acerque a mi ventana. Ni la piedra mssegura ni la ms lejana: la que te acerque a mi ventana. Y Hans lleg y lleg ylleg. Y Boris, nieto de Hans y Frida y entrenador de Scrum que me relat estaancdota all lejos y hace tiempo, naci...unas dcadas ms tarde.

LA VISIN Y SCRUM[Ro caudaloso]

Si Hans tuviese memoria fotogrfica, podra haber seguido el caminorecorrido la ltima vez cada da? No, no y no. El ro corre y el contexto, por msque a simple vista el proyecto sea el mismo, cambia y con ello debida la marchadel nuevo proyecto. Stanislavsky dijo que una gran interpretacin de un actor es


6/38

una rosa marchita. La siguiente vez el actor pierde tiempo y energa tratando derevivir esa rosa: lo nico que puede hacer es plantar una semilla y mantener sumirada con claridad en el objetivo, mas no en las formas, que sern nicas eirrepetibles cada vez.

LA VISIN PARA ESTE LIBROUna visin es un cuadro que pinta un escenario feliz al finalizar un proyecto.

Cmo se ve el mundo si este proyecto llega a ser un xito? La visin debeservirnos para poder decidir con claridad hacia dnde saltar: Por qu hacereste proyecto? Por qu nosotros? Cul es la medida de xito?

Aprender Scrum es un proyecto en su mismo. La lectura de este texto lo es.Definamos entonces una visin para este libro:

Comprender por qu Scrum es muy simple, muy difcil y funciona en elcontexto adecuado. Por funcionar entendemos que ayuda a mejorar laproductividad, la calidad y la felicidad de quienes toman parte de un proyecto

Que pasar si se cumple esa visin? Pues ser hora de tomar una decisin:

Scrum no es para m: mejor no seguir malgastando mi tiempo aqu

S lo es: entiendo que siempre voy a estar transitando el arduo e interminablecamino que significa utilizar Scrum

Ese maldito martillo[Persona como engranaje]

Desde hace ya dcadas que venimos leyendo sobre el advenimiento de la

era de la informacin. Hemos escuchado a decenas de gerentes decir frasesrimbombantes como ser "nuestro principal capital es el humano". Cada vez esmayor la proporcin de los llamados trabajadores del conocimiento en laempresa moderna. Ao a ao valor agregado significa produccin deconocimiento, desarrollo de productos novedosos. Y sin embargo la miradapredominante del mundo laboral no ha cambiado. Dueos, jefes y empleados


7/38

siguen con el mismo modelo mental de antao: el paradigma industrial. rdenes,control, procedimientos, cumplimiento, predictibilidad, lneas de produccin,uniformidad, premios y castigos. La persona es un recurso, como tambin lo sonlas sillas y las maquinarias. Si se rompe o se pierde, se cambia. No sabe cmo

cambiar ese recurso? Pues mire el procedimiento, siga los pasos y listo.Esta disfuncin es real y perjudica a las empresas, pero sobre todo a las

personas que trabajan en ellas. Tal vez sea hora de cambiar el paradigma haciauno que explique mejor la realidad que vivimos da a da. Todo parece indicarque la tierra es redonda, pero cuesta tanto tanto sacarnos de la cabeza esa tablahaciendo equilibrio sobre una tortuga.

TRABAJADORES DEL CONOCIMIENTO: TU Y YO[Lamparita]

Eres un trabajador del conocimiento porque vales por lo que sabes, poraquello que puedes comprender y, por sobre todas las cosas, por tu capacidadde innovar. Eres til porque generas informacin trabajando en colaboracin contus pares. Ayudas a construir lo que no existe trabajando en un equipo que estalineado con una estrategia. Eres un trabajador del conocimiento porque puedesestablecer relaciones entre conceptos, comprender causas y efectos, eres capazde crear una estrategia y balancear el pensamiento convergente con eldivergente. Eres un trabajador del conocimiento porque eres desarrollador de

software, gerente de proyecto, mdico, abogado, arquitecto, publicista,ingeniero, cientfico, bibliotecario. Trabajas produciendo conocimiento y por ellotu trabajo no es ni mecnico ni predecible y tu capacidad se ver cercenada alser regida por completo por procedimientos rgidos definidos por un tercero. Y talvez lo ms importante: el conocimiento es tuyo y puedes ir con l a donde teplazca.

MARTILLANDO CLAVOS[Ford T + operario]

De qu hablamos cuando hablamos del paradigma industrial? Hablamos delFord T. De Henry Ford anunciando con una sonrisa envidiable que sus clientespueden elegir el color de su auto mientras sea negro. De una lnea deproduccin, a lo largo de la cual distintos trabajadores cumplen de formarutinaria un trabajo detallado en un procedimiento, redactado por su superior,


8/38

quien posee ms educacin y/o experiencia que el obrero raso. El procedimientoindica claramente la forma de trabajar: llega la carrocera, se ubican tres clavosen cada eje y se martilla a gran velocidad. Si el obrero se equivoca, se enferma,muere o se sindicaliza ser cuestin de horas, tal vez minutos, tener un

reemplazante que iguala y hasta mejora la productividad del anterior. Elconocimiento en esta funcin es explcito: no est en la mente del trabajador,sino que se encuentra descrito de principio a fin en el procedimiento. El obrerosolamente aporta su fuerza, no su intelecto, al menos desde la visin msclsica industrial. Es as como, a medida que pasaron las dcadas, los obrerosfueron fcilmente reemplazados por mquinas. Quin contina siendoimprescindible? El equipo de ingenieros que disean y mejoran la lnea.


9/38

TODO ES RELATIVO

Veamos este grfico. Su objetivo es describir lo que vamos a llamarcomplejidad relativa de un proyecto. En el eje horizontal figura nuestraexperiencia, nuestro conocimiento de las herramientas con las que trabajaremos

en este proyecto. A qu me refiero cuando hablo de herramientas? Abramosnuestro horizonte: tcnicas de dibujo, lenguajes de programacin, brainstorming,buenas prcticas de manejo de proyectos: lo que sea que utilizamos paradesarrollar el producto asociado al proyecto. Cuanto ms a la derecha nosubiquemos en este eje, mayor ser nuestro desconocimiento de la herramienta.No solamente es novedosa, sino que, por sus caractersticas, es difcil de utilizar.


10/38

Es importante resaltar que en este caso la herramienta es novedosa y difcilparanosotros. El proyecto es complejo en trminos relativos.

Qu ocurre en el eje vertical? En este caso se plasmar la complejidad delos requerimientospara nosotros. Si nos posicionamos hacia abajo estamos en

una situacin cmoda: tanto el cliente como nosotros entendemos qu es lo quehay que hacer de manera precisa, sin duda alguna. Si nos vamos hacia arriba enel eje aparecen las dudas, la falta de certezas, la probabilidad de que hayamodificaciones en los requerimientos a mitad de proyecto.

Vamos a dividir el grfico en tres tipos de proyectos. Tres clases de proyectosradicalmente distintos. Distintos enfoques para distintas realidades:

Los proyectos simples: conocemos las herramientas y los requerimientos.Podemos planificar sin temor a equivocarnos. Los resultados son previsiblesaunque no hay demasiado lugar para los cambios. Bajo riesgo y, por ende, bajaposibilidad de innovacin. Cul es la manera ptima de trabajar en estosproyectos? La lnea de produccin: cada etapa de la lnea se encuentratrabajando en un producto distinto, lo que maximiza la productividad. Ensoftware tenemos un equivalente ms que claro: el desarrollo en cascada.

Los proyectos caticos: comienza el proyecto y parece como si hubiramosdespertado en medio de un mar encabritado. No sabemos para donde ir ni cmose nada. Puede ser que terminemos el proyectoalgn da. La investigacin

cientfica vive en el caos. Solamente hay una manera de sacar esto adelante:prueba y error, prueba y error.

Los proyectos complejos: entre la simpleza y el caos se ubica la complejidad.Aqu residen los proyectos tpicos que encaramos los trabajadores delconocimiento. Riesgosos, creativos, pero con grandes posibilidades de xito.Qu hacer en este caso? Probemos con Scrum

POR QU DEBERAS AMAR LOS LMITESSegn la mitologa griega Caos era lo nico que exista antes de que

apareciese el mundo, el cosmos. A partir del caos todo es posible. Innovar,descubrir, inventar, crear. Queremos crear, pero debemos ser productivos. Lostrabajadores del conocimiento debemos ser predecibles. Para aprovechar lomejor de ambos mundos vamos a crear una forma de trabajo que nos permitavivir en un equilibrio inestable. La propuesta: surfear el borde del caos.


11/38

Para pensar el cmo hagamos un pequeo ejercicio mental. Empecemos.Levanta la vista y s creativo. Ya. Ya mismo. Difcil, no? Y qu tal si te pidoque dibujes? Tal vez la mente la tengas menos en blanco ahora, peroseguramente cuesta empezar. Y si te pido que dibujes con lpiz en una hoja

A4? Cuesta, pero menos

Y si agrego que solamente puedes dibujar crculos ytienes dos minutos? Ahora s, ests listo para la accin. Tu mente no est seguradel resultado final, pero tiene el impulso necesario para comenzar y ser creativa.Logramos fijar la cantidad mnima de lmites a ese mar embravecido que es laabrumadora infinitud de posibilidades de un universo catico para caer en unentorno ms controlable: la complejidad.

Saber hacer Scrum va a ser similar a canalizar el rumbo del agua de martierra adentro: dentro del canal seguimos teniendo aguas turbulentas que nos

permiten probar, innovar, equivocarnos. Pero sern las paredes del canal las quenos permitirn llevar el agua turbulenta hacia el destino al que nos interesaarribar. Scrum es el arte de balancear lmites con libertad, para poder sercreativos y productivos a la vez. Como un periodista, que tiene lista esa nota deopinin polmica y elegante en dos horas, justo antes del cierre de la edicin dehoy.

Pero sigamos: ahora solamente puedes dibujar tres crculos, del mismotamao y que stos se toquen entre si. Aburrido, no? Demasiados lmites nos

llevan de lo complejo a lo simple. Antes de empezar ya te imaginas el resultado.Puedes hacer el ejercicio decenas de veces y seguir siendo bastantepredecible el tipo de dibujo que obtendrs. En los proyectos simples en trminosrelativos es fcil predecir el producto y cmo hacerlo. Pero para un alma inquietacomo la de un trabajador del conocimiento los proyectos simples sonsimplemente aburridos.

SCRUM NO HACE NADAVamos a plantear otro tipo de complejidad: la absoluta. Para eso recurrimos aAristteles y un anlisis muy simple que hizo de los problemas. En primertrmino un problema tiene una complejidad esencial. Esta complejidad esinherente al problema. Es irrompible, nadie ni nada podrn jams simplificarlo.

[El cerro Torre]


12/38

A ver, vamos con una ancdota para tratar de tomar el concepto por lasastas. En la Patagonia sur, al sur del sur de la Argentina, que queda muy al sur,hay una serie de pequeas cadenas montaosas hechas de granito entre mediode los Andes. El granito, como todos sabemos, es muy duro. Entre estas

montaas de granito se encuentra el Cerro Torre. Muy poco vistoso perobastante vertical, es considerado por muchos como uno de los mayores desafosque puede llegar a enfrentar un alpinista. El Cerro Torre no solamente estcompuesto de granito, sino que adems es prcticamente vertical y se veazotado de forma casi permanente por fuertes vientos. En 1959 un italianollamado Maestri subi con un colega austraco pero baj solo: el pobre amigoteutn haba fallecido en el camino. Maestri cont al mundo, champaa enmano, que haba llegado a la cima. Pero, oh fortuna injusta eres, el austracollevaba la cmara de fotos y una avalancha se los haba llevado a ambos alaverno. Dudas, suspicacias, aos de orgullo herido y Maestri, harto de tantocomentario cizaero, decidi hacia 1970 mostrarle al mundo que quien escala elCerro Torre una vez, lo hace dos. Esta vez no iban a quedar dudas. Ningunaduda. Maestri emprendi camino junto a una verdadera troupe que pudiera nosolo comprobar sus hazaas sino sobre todo llevar el taladro neumtico, con sucorrespondiente compresor, con el que termin agujereando la temible pared degranito que lleva a la cima. Cmo logr Maestri llegar a la cima? No lleg enhelicptero, pero casi. Cambi el juego: dej de hacer alpinismo y se puso el

casco de ingeniero civil. O, puesto en trminos aristotlicos, disminuy lacomplejidad esencial de un problemacambiando el problema! Tentacin en lacual caemos muchos trabajadores del conocimiento cuando nos damos cuentade que somos incapaces de resolver un problema que se nos plantea. Laomnipotencia intelectual nos traiciona de a ratos y nos vuelve un poco Maestri.

La leccin? Scrum podr ser maravilloso o podr no serlo, pero seguro noresuelve el problema en si. Tenemos que estimar el costo de un proyecto dedos aos de duracin del que participarn quince personas que no se conocen

entre si? Eso es muy complejo y no hay Scrum que lo resuelva. La pregunta esentonces: Para qu sirve Scrum entonces? Sigamos con Aristteles, quesiempre suena elegante citarlo. Como se ve en el dibujo, siempre que nosenfrentemos a un problema deberemos lidiar no solamente con la complejidadesencial, sino tambin con la complejidad accidental. Esa complejidad no espropia del problema, sino que viene de regalo. En la filosofa de gestin Lean, de


13/38

la cual no importa si has escuchado antes o no, se habla del desperdicio oesfuerzo que no aporta para resolver el problema en si mismo. Lean significamagro: con poco o nada de grasa. Pensemos entonces en la complejidadesencial como la carne y los huesos y en la accidental como la grasa

innecesaria. Hay grasa cuando no confiamos en nuestro jefe ni l en nosotros.Hay grasa si la silla es incmoda y el bao de la oficina huele mal. El proyectose hace innecesariamente ms complejo. Para esto sirve Scrum: para detectarla capa de grasa ms voluminosa y enfrentarnos cara a cara con ella. Scrum esuna pequea maquinita que hace que emerjan las disfuncionalidadesorganizacionales. Cmo se resuelven estas disfuncionalidades? Hay tantasrespuestas como situaciones: Scrum no se inmiscuye: es solamente elmensajero de la malas nuevas. Matarlo o escucharlo es decisin de quien loutiliza.

SIMPLEMENTE PLANTA UNA SEMILLAY cmo funciona la maquinita? Presentemos primero un concepto: el

desarrollo iterativo incremental. Iterar significa literalmente repetir un mismo

proceso. Entendmoslo comenzando por su opuesto, el desarrollo lineal. Eldesarrollo lineal consiste en armar sesudamente un plan para luego ajustarse al e ir revisando peridicamente su cumplimiento. Esto se denomina usualmente

project tracking. Durante el transcurso del proyecto la idea no es cambiar el plan,sino meramente saber si venimos cumplindolo en tiempo y forma. Este enfoqueinflexible no suena muy conveniente para un proyecto complejo, pero sin


14/38

embargo es el ms utilizado a la hora de firmar un contrato. Armamos un plan yfirmamos con nuestra sangre que lo cumpliremos. Luego solo resta ircomprobando que todo va sobre rieles. Lo que se dice ilusin de control.

La alternativa que proponemos es el desarrollo iterativo. ste no es ms que

esbozar brevemente un plan a mediano plazo, para luego saltar de piedra enpiedra, reajustando el prximo salto en funcin de la informacin que obtuvimosluego del ltimo salto. Esta alternativa promete menos exactitud el da delcomienzo del proyecto, pero sin dudas tiene muchsimas ms chances de llegara destino a la hora de cruzar un arroyo caudaloso en una neblinosa nochebvara. En este caso hablaremos de llevar el proyecto haciendoproject steering.Es decir que de antemano nos estamos dando espacio para poder maniobrar amedida que pasa el tiempo y avanza nuestro trabajo. Confiar en el terreno ms

que en el mapa.

Espero que estn de acuerdo conmigo: para un proyecto complejo la mejoreleccin es el desarrollo iterativo. Ya tenemos la base sobre la que nospararemos para pensar en cmo podemos desarrollar el producto. Vamos a


15/38

presentar dos maneras de hacer las cosas. La primera la llamaremos desarrollomodular. Supongamos que tenemos un cliente que nos pide que leconstruyamos una pelota grande. Digamos de unos 60cm de dimetro. Si vamosa construir esta pelota de manera modular, querremos que como producto de

nuestro primer salto ya haya un diseo detallado de cmo ser nuestra pelota.Sus materiales, su comportamiento ante distintas superficies, cmo vamos aprobar que funciona. Luego vendr el segundo salto, en el que construiremos unarco, claro est. En el siguiente salto un segundo y luego un tercero ydadoque es un proyecto complejo, hemos estimado mal en nuestra planificacininicial, y se nos acab tanto dinero como tiempo. No nos queda otra alternativaque recibir al cliente y llevarle el producto que tenemos: tres arcos. El pobrehombre nos mira y nos pregunta qu demonios es eso que traemos entremanos. Si nuestro cliente esperaba obtener 100 (pesos, duraznos, sonrisas, daigual) acaba de obtener un rotundo 0. [Grfico de desarrollo modular, indicandoque los arcos valen 0]

La alternativa al desarrollo modular la vamos a denominar incremental o,mejor an, orgnica. Cmo se construira la pelota en cuestin de maneraincremental? Antes de comenzar realizamos un rpido bosquejo del diseo delproducto que vamos a construir. Al igual que los planes iterativos, los diseosincrementales comienzan como una idea vaga, falta de detalles. Lo mnimoindispensable para marcar el rumbo y comenzar a saltar hasta la prxima piedra.

Al concluir la primer iteracin obtenemos no un arco, sino una pelotachiquitita. El dibujo de la pelotita tiene la misma cantidad de tinta que el primerarco construido de la manera modular. La diferencia? Al final de esta primeriteracin podemos llamar al cliente, darle la pelotita y pedirle que la use. Elhombre toma la pelota, la lanza cual bola de boliche por su jardn y, dado que enla casa de este seor hay un gran problema de filtraciones y el pasto estconstantemente embarrado, la pelotita avanza unos centmetros y se frena. Elcliente nos mira con ceo fruncido y nosotros lo tranquilizamos dicindole que

ambos acabamos de aprender algo: no sirve que la pelota tenga una superficietan lisa. "Yo no vine a aprender nada ac. Pagu y quiero una pelota que ruedepor mi jardn.". Lgico, el cliente quiere valor. Le explicamos que acabamos deahorrarnos dinero, dado que la prxima versin de la pelota ser rugosa.

Luego de la segunda iteracin obtenemos una pelota que ya parece ms bienuna piedra. De qu tamao es la nueva pelota? Si queremos hacer desarrollo


16/38

incremental, pues deber ser ms grande que la anterior. No estaramospracticndolo si hubisemos desechado la primer pelota y hubiramoscomenzado de nuevo. Debemos construir nuestro producto de forma tal quepueda crecer. Pues entregamos la versin rugosa al cliente, quien la arroja por

su jardn. Rueda que te rueda, la nueva pelota llega hasta la casa del vecino.Nos miramos a los ojos con el cliente y decimos al unsono: "demasiado". Elcliente quiere que este objeto (que cada vez se parece menos a una pelota)ruede unas cinco o seis veces, no ms. Es caro, le explicamos y ya casi se nosacaba tiempo y dinero, pero podemos ofrecerle una pelota que ruede una solavez. Asiente con la cabeza y nos lanzamos a trabajar en la ltima iteracin. Senos acab el presupuesto, pero el cliente tiene ya una pelota que ruedaexactamente una vez. De los 100 que haba pensado obtener de este proyectotiene en mano un producto que vale, digamos, 70. No es el ideal, pero esbastante ms que el 0 que habramos obtenido si construamos una pelotaperfectamente esfrica, que no habra hecho ms que enterrarse en el barro.

La diferencia en el modo de construccin nos permiti obtener feedbacktemprano.Por qu no podramos haberlo obtenido construyendo de formamodular? Pues simplemente porque una serie de arcos no puede ser utilizadapor el cliente. Qu ganamos con el feedback? Entendemos, cliente ydesarrollador, qu es lo que se necesita. En un proyecto complejo el producto aconstruir es complejo, por lo que es imposible definirlo con precisin a priori,intelectualmente, sin, literalmente, embarrarnos en el proceso de aprendizaje.Pero no solamente entendimos mejorqu se necesitaba, sino que adema


17/38

Tuvimos un producto y un plan maleables, lo que nos permiti adaptarnos alos cambios que implic el entender mejor de qu se trata el producto. Y todavahay ms! Construir incrementalmente nos permiti entregarvaloran habiendo

estimado de manera inexacta en un comienzo duracin y costo del proyecto.

Vamos con un ejemplo ms: esta vez nuestro cliente nos pide queconstruyamos en su jardn un rbol que le d sombra a 30 personas. Decidimosconstruirlo de manera orgnica. Hacemos un pequeo pozo en un rincn,plantamos una semilla y regamos una vez al da. Luego de nuestra primeraiteracin tenemos con nosotrosun rbol! Solemos llamar a esto un brote, peroen trminos del desarrollo iterativo incremental ya tenemos un producto queentrega valor. Por qu? Porque cumple con la definicin de un rbol: tiene un

diminuto hilo que toma nutrientes y agua del suelo (que vamos a llamar raz),se sostiene apenas con un palito (que vamos a denominar tronco), que es a suvez verde, dado que tiene clorofila, y que por ende va a realizar fotosntesis (aesto llamaremos hojas). Y seguimos iterando y nuestro arbolito crece y crece.Hasta que un da el vecino decide construir una casa al lado de nuestro rbol. Lanaturaleza es sabia y el rbol, previa poda, contina su crecimiento hacia el ladoopuesto a la pared. Y tanta mala suerte tenemos que el alcalde decide construiruna ruta al otro lado de nuestro rbol. Previa poda, nuestro rbol seguir

creciendo, pero a partir de la altura del camin ms grande que suela pasar porla ruta. Se nos acaba el tiempo y dinero presupuestados. El rbol da sombra aunas 18 personas. El cliente frunce el ceo. Esperaba 30, obtuvo 18. Fue lomejor que se pudo.

Tal vez si hubisemos construido el rbol de manera modular nos habra idomejor. Probemos: invertimos una semana diseando por completo el producto,de forma tal que resulte econmico tener un rbol que d sombra a 30 personas.Una vez obtenido el plano alquilamos una excavadora. Segn nuestros clculos,necesitamos races que alcancen los 10 metros de profundidad. Mientras latopadora avanza nosotros comenzamos a amasar una serie de robustas races,que soporten todo el peso de un rbol del porte que necesitamos. Comenzamosa cubrir con tierra nuestras primeras grandes races cuando sentimos quealguien nos toca el hombro: es el vecino, para contarnos que va a construir unacasa al lado de nuestro rbol. Llamen a la topadora de nuevo! Y de vuelta altablero de diseo. Y a serruchar las races que con tanto amor y expectativas


18/38

habamos tallado. Luego de semanas de trabajo estamos listo para comenzarcon el tronco. Pero de repentealguien nos toca el hombro: es el alcalde, paraavisarnos que va a construir una ruta al lado del rbol. El tablero de diseo, latopadora y nuestros nervios vuelven a pura furia. Perdemos nocin del tiempo y

tallamos las nuevas races con dedicacin, pasin y bastantes nervios. Hastaque nos vuelven a tocar el hombro: es el cliente. Se termin el tiempopresupuestado y le preocupa un poco ver solamente un poco de tierra revuelta.Lo miramos con desconcierto y pedimos un poco ms de tiempo, plano enmano. Valor entregado: ni un poco de sombra. Al construir modularmente nologramos adaptarnos a los cambios en el contexto.

Resumiendo, el desarrollo orgnico permite:

Adaptar plan y producto a cambios en el contexto

Entender mejor, mediante el feedback obtenido del cliente, qu producto esnecesario

Adaptar plan y producto a los cambios producidos por este mejorentendimiento

Entregar valor an habiendo estimado la duracin de forma imprecisa alcomienzo del mismo

Nada mal para un proyecto que surfea el borde del caos

Las reglas del juego

MI PROCESO, TU PROCESO, CUL PROCESODefinamos una palabra, al menos a lo largo de este texto: proceso. Proceso

ser para nosotros "la forma en la que trabajamos". El proceso puede ser

catico, emprico, definido. Es parte del proceso que sepamos trabajar enequipo, que haya goteras en la oficina, que no me quiera ni hablar con el gerentede recursos humanos, que tenga que reportar hora a hora en qu trabaj al finalde cada da. Todo eso es proceso.

Metodologa ser un proceso definido, en el que existen respuestas para laspreguntas cmo?, cundo?, quin?, se puede?. Scrum no es una


19/38

metodologa. Scrum ni siquiera es un proceso. A lo sumo podramos definirlocomo un metaproceso: una maquinita que nos ayuda a construir iterativa eincrementalmente nuestro propio proceso. Por qu? Porque al decidir utilizarScrum estamos tomando una decisin, una postura frente al proyecto que

estamos por llevar a cabo: definir el proceso ideal para un proyecto que tienecomo objetivo construir un producto complejo es complejo en si mismo. Por endevamos a repetir el enfoque: el proceso crecer y se adaptar a nuestroaprendizaje y a los cambios de contexto orgnicamente.

Scrum es por ende un framework o marco de trabajo, que ser el andamiajeque nos va a ayudar a encontrar, iteracin a iteracin, el mejor proceso posibledada nuestra realidad y nuestros potenciales.

TAN SIMPLE COMO UN PASO A LA VEZLa base de Scrum ser el desarrollo iterativo e incremental de producto y

proceso. En concreto se plantea una dinmica de pequeos saltos. Cada saltova a consistir en

Planificar hacia dnde saltar (teniendo en cuenta la visin)

Ejecutar el salto (Saltar, qu tanto!)

Inspeccionar tanto el avance producido por el salto como la manera de saltar(producto y proceso respectivamente)

Adaptar la direccin del salto (producto) y la manera de saltar (proceso),para acercarnos ms y mejor al objetivo final

[Un salto con un pie, giro y luego un salto con ambos pies]

Saltar y saltar hasta que ocurra alguno de los siguientes eventos

Llegu a destino! El proyecto fue un xito: alcanc la visin.

Se nos acabaron tiempo y/o dinero: llegamos hasta donde pudimos llevando

al lmite nuestras posibilidadesDecidimos que no vale la pena seguir saltando. Cancelamos el proyecto. Tan

horrible y decepcionante como suena, nunca hay que olvidar el dicho turco quedice "no importa cunto hayas caminado, si es la ruta incorrecta entoncesvuelve". Aunque a nuestro orgullo le duela en el alma, a veces la decisin mssabia simplemente es volver.


20/38

QUINExisten tres roles en Scrum, que fueron elegidos para dividir de manera clara

y simple perspectivas y responsabilidades entre ellos. Para comprender mejoresta divisin vamos a tomar una vieja definicin de tctica y estrategia: tctica esla mejor manera que encontramos de ganar una batalla y estrategia es la mejoreleccin de batallas que decidimos en pos de ganar la guerra. Es decir, entrminos de un proyecto, la estrategia estar dada porqu caractersticas tendrel producto y la tctica porcmo se desarrollarn dichas caractersticas.

Equipo de desarrolloY ahora s, a por el primer rol: el equipo de desarrollo (o muchas veces

"equipo" a secas). El equipo de desarrollo es un grupo, usualmente entre 5 y 9personas, queposeen todos los skills necesarios para construir un producto quecumpla con la visin. Por ejemplo, para un desarrollo tradicional de software,necesitaremos programadores, testers y tal vez diseadores grficos y expertosen usabilidad dentro del equipo. Se deduce de esta definicin que el equipodebe sermultidisciplinario.

El equipo tiene claramente la responsabilidad y la perspectiva de la tctica/el

cmo de la construccin delproducto.

Product OwnerEl Product Owner es un individuo que posee como responsabilidad maximizar

el retorno de inversin del proyecto. Es decir que, desde una perspectiva


21/38

estratgica, debe indicar el qu delproducto, enarbolando cual faro la visin delproyecto.

Por qu una sola persona y no un equipo? Porque la experiencia nosmuestra que en los proyectos en los que participan los trabajadores del

conocimiento la principal causa de fracaso suele ser la mala comunicacin a lahora de transmitir los requerimientos al equipo. Por eso nombramos a uno y sloun embajadorde los stakeholders, que son todos aquellos que tienen interesesen el proyecto y la potestad para imponer esos intereses. Cualquier proyectotiene variopintos stakeholders, con intereses y perspectivas contrapuestas. ElProduct Owner es responsable de representarlos de la mejor manera posibleante el equipo, evitando de este modo potenciales ambigedades a la hora dedefinir las caractersticas del producto.

Scrum MasterProduct Owner y equipo de desarrollo tienen sus ojos y su energa

concentrados en una sola cosa: el producto. Y dado que no hemos dicho nadasobre cmo deben trabajar podemos afirmar que conforman un gran equipoauto-gestionado. Dado que ellos son quienes estn da a da enfrentndose caraa cara con la realidad del proyecto, quin mejor para decidir elproceso que ellos

mismos. Si aceptamos que el proceso que necesita un equipo para desarrollarde manera ptima un producto complejo es complejo en si mismo, no podemosquedarnos en la nocin industrial (Se acuerdan del viejo paradigma?) en la queun supervisor decide desde fuera cmo debe trabajar el empleado. Eso estmuy bien para martillar clavos, pero en el caso de un proyecto complejo, en elque no nos queda otra alternativa que apelar al lado ms humano de los


22/38

trabajadores, perderamos potencial creativo y, sobre todo, compromiso con elresultado final si impusisemos proceso.

Pero la auto-gestin no es ninguna panacea per se. Es simplemente unllamado a gritos al caos. Y ya vimos lo interesante, pero tambin lo riesgoso que

puede ser el caos. Necesitamos lmites, pero queremos que esos lmites seanauto-impuestos. Traigamos a escena a una tercer figura, que acte de espejotanto para el equipo de desarrollo como para el Product Owner, para recordarleslos lmites que nos impone Scrum, a fin ayudarlos de canalizar el caos y llevar abuen puerto un proyecto que necesita de altas dosis de creatividad. Traigamos aun ScrumMaster.

El ScrumMaster, adems de tener un nombre grandilocuente, es una figurapoco tradicional en las organizaciones. El ScrumMaster es ni ms ni menos que

un espejo: es responsable, desde una perspectiva de proceso, de que ProductOwner y equipo de desarrollo optimicen y utilicen una manera de trabajar cada

da mejor. Para ello un ScrumMaster suele llevar a cabo tres labores bsicas:

Facilitador: alguien que ayuda a un grupo de personas a tomar una decisinno trivial desde un punto de vista neutral

Coach: un evocador de excelencia - soplador de brasas, que supieron serfuego y necesitan ser avivadas

Mentor: maestro que instruye desde una posicin de igualdad y procura queel mentoreado siga su propio camino lo antes posible

El ScrumMaster suele llevar una sola herramienta en su bolso: la pregunta.Puede ser insidiosa, bsica, generadora de silencios incmodos, cndida,retrica. Las hay de todo tipo y color y, a diferencia de las respuestas, son ellaslas que mueven al mundo.


23/38

QUVimos el predicado, luego el sujeto: le lleg el turno al objeto, a lo que en

software se denominan artefactos. Documentos? No necesariamente, sinomeras herramientas de trabajo que son utilizadas constantemente por los tresroles durante un proyecto que utilice el framework. Cada una de ellas tendr unresponsable.

VisinLa visin, como vimos anteriormente, es esa vela ubicada en la ventana. Esa

descripcin somera del norte que debe llevar el proyecto. El responsable de que

la visin sea lo ms representativa posible de las necesidades y potestades delos stakeholders es obviamente el Product Owner. El responsable de que elequipo comprenda la visin y desarrolle el mejor producto posible en trminos dela misma es el Product Owner. Esto no significa que sea l mismo quien laredacta. Solamente es responsable de que eso suceda. Quin la escribeentonces? Depende. Es decir, el framework deja, adrede, esa pregunta, comotantas otras, sin responder. Por qu? Porque ofrecer una respuesta universalen este caso sera cercenar las posibilidades que nos brinda dejar este aspectosin lmite alguno. Scrum es, recordemos, equilibrio inestable. O lo que es igual,el balance entre lmites y libertad.

[Letra "S" caminando en una cuerda floja]

Product BacklogLa palabra "backlog" podra traducirse como "lista de lo que me falta para".

El Product Backlog ser entonces la lista de caractersticas de las que carece


24/38

hoy en da el producto. En l se ve plasmada la estrategia del proyecto. Elresponsable de tener el backlog que marque el mejor recorrido posible hacia lavisin ser obviamente el Product Owner. Por eso decimos que es elresponsable de este artefacto. Nuevamente, esto no significa que es el Product

Owner quien construir el Product Backlog. Esto, nuevamente, depender delcontexto. Cada vez que mencionemos a los stakeholders, usualmente querrdecir que es el Product Owner quien dialoga cara a cara con el equipo, dado quesu principal atributo es el poder conjugar las distintas necesidades de todos losinteresados en el proyecto en un nico mensaje.

El Product Backlog es simplemente una lista de lo que llamaremos, aunquesea confuso para nosotros los hispanohablantes, PBIs: Product Backlog Items.El framework no prescribe cmo se materializan los PBIs. Alguno ser lo que en

software llamamos Caso de Uso, algn otro en la lista ser una Historia deUsuario y unos cuantos tal vez sean meras servilletas garabateadas. Elframework solamente describe dos caractersticas de los PBIs:

Cada vez que el equipo desarrolle un PBI el producto habr aumentado elvalor percibido por los stakeholders (crecieron races, tronco y rama hasta darlesombra a una persona ms)

Los PBIs se encuentran ordenados de acuerdo a su prioridad

Y ahora la pregunta de rigor: Para qu pide esto el framework?

El primer punto es la manera de poner en prctica el desarrollo o crecimientoorgnico del producto. Cada salto entre piedra y piedra nos acerca de maneraconsolidada (o no nos acerca, en caso que el equipo haya construido un PBI demanera incorrecta) a la visin. Su aceptacin por parte del Product Owner serbinaria: brinda valor o no lo brinda. No es un PBI un arco de la pelota osolamente una rama. Que el PBI entregue valor a los stakeholders nos aseguraque se ha crecido de manera tal que nada a quedado a medias: si hemosestimado mal el proyecto quedaremos bien parados (tendremos producto para

entregar - le habremos dado sombra a un nmero de personas) y, msimportante an, slo as recibiremos feedback til de los stakeholders, dado queellos tienen la perspectiva de negocio, de valor. Un PBI incompleto es aquelbatalla que an no se ha decidido y por lo tanto sera contraproducente tomardecisiones estratgicas basadas en puras especulaciones.


25/38

[Salto de una piedra a otra es PBI/Salto a medias no es PBI=> podraterminar en una cada al agua!]

El segundo punto (que los PBIs tengan un orden, una prioridad) essimplemente la manera de hacer que el crecimiento orgnico juegue a nuestro

favor. En el viejo paradigma, el Ford T se hace completo o no se hace. Ennuestro caso se hace todo lo que los stakeholders piden al comienzo delproyecto o fracasamos. En Scrum, como ya lo vimos en los ejemplos dedesarrollo iterativo incremental, hacemos algo bastante bueno que, segn elproverbio chino, es enemigo de lo perfecto. La lgica es simple: dado queadmitimos que existe la posibilidad de que no lleguemos a desarrollar todo loprometido, construiremos aquellas caractersticas prioritarias primero, de formade maximizar el valor entregado a los stakeholders.

[Repetir dibujo de desarrollo orgnico de la pelota con una flechita que diga"Lo ms importante para el cliente era que la pelota ruede - no fue tan grave queno hayamos llegado a construir una pelota que rebote!)

Por ltimo, nos adelantamos a la presentacin del flujo completo delframework, presentando la relacin existente entre el Product Backlog y elequipo. Al comienzo de cada iteracin el equipo se comprometer a entregaruna porcin del Backlog al final de la misma. Luego entraremos en mayor detalleen este punto, pero aprovechemos para bautizar a este subconjunto de PBIs

como Backlog Comprometido.[Grfico de backlog en verde y comprometido en rojo] Sprint Backlog

El Sprint Backlog materializa la tctica utilizada por el equipo para desarrollarPBIs durante una iteracin (que en Scrum llamaremos Sprint). El equipo serobviamente el dueo, el responsable de esta herramienta. En ella se vernplasmadas las tareas que consideren necesarias para poder entregar al final delSprint los PBIs a los que se han comprometido. Veremos en breve en qu

momento del Sprint se produce este compromiso. Incremento del producto potencialmente entregableLlegamos, por fin, al artefacto para el que, al fin y al cabo, decidimos usar

Scrum: el producto. Al finalizar el Sprint el equipo presenta qu PBIs hadesarrollado, lo que brinda a los stakeholders, dado que cada PBI de manera


26/38

individual hace crecer orgnicamente el producto, un resultado que a priorientrega valor.

Se dice que el incremento es entregable porque cumple con lo que daremosen llamar el "criterio de listo". Vamos a definir que algo est listo cuando "nadie

debe preocuparse ms por eso". Por ejemplo, imaginemos una pareja que acabade volver del trabajo. El marido decide cocinar fideos, mientras la mujer ordenala ropa. Gente muy hacendosa ellos dos. La mujer pregunta desde la habitacinsi la comida est lista. El marido responde que no, que en cinco minutos. Al cabode un rato la mujer insiste y el marido, orgulloso, responde que s, que la cenaest lista. La mujer se dirige raudamente a la mesa y encuentrapapelesdesordenados y un vaso medio vaco. Le pregunta al esposo qu pasa: nisiquiera est hecha la mesa! El marido, sorprendido, le contesta que los fideos

estn listos, lo que significa que la cena est lista. Ahora resta servirlos enplatos, limpiar la mesa, etc, etc. Quin tiene razn? Ambos! Cul es elproblema? Que ambos tienen distintos criterios de listo. La consecuencia? Nosolamente el enojo de ambos, sino que las decisiones (minsculas en este caso,millonarias en muchos proyectos) se tomaron segn el propio criterio de listo. Siun equipo entrega a un Product Owner un PBI listo, a menos que ambos sehayan puesto de acuerdo en lo que eso significa, puede producir un granproblema tiempo despus de la entrega. Vamos con otro ejemplo del software,que es la disciplina en la que ms se utiliza Scrum: un equipo entrega

funcionalidad tras funcionalidad durante varios Sprints. Luego, por un cambio enla situacin del mercado, el Product Owner comunica que hay que variar laestrategia y realizar algunos cambios sobre el software existente. El equipoexplica que eso es muy riesgoso, dado que no se hicieron pruebas sobre lo yaentregado. El Product Owner tiene, digamos, palpitaciones. Cmo se previene?Simplemente explicitando cul ser el criterio. Quin es responsable de queest definido de la mejor manera posible: claramente el Product Owner, pues esel responsable de definir qu condiciones debe cumplir un PBI para entregar

valor de negocio.

Process/Impediment BacklogExplicamos hace ya varias pginas que en Scrum se desarrollan

orgnicamente tanto producto como proceso, dado que se considera a priori que


27/38

ambos son complejos. El mejoramiento o construccin del proceso puede servisto con dos tipos de lentes

Mitad del vaso lleno: la organizacin posee un conjunto de virtudes que pueden ser

potenciadas

Mitad del vaso vaco: la organizacin posee un conjunto de problemas que pueden ser resueltos

Tal vez por su origen ingenieril, la inmensa mayora de las implementacionesdel framework privilegian la segunda mirada por sobre la primera. Es por esoque vamos a denominar impedimentos a cada uno de los Process BacklogItems. Cada tem es entonces un problema, una situacin, una complejidadaccidental que nos impide ser ms productivos, desarrollar productos con mscalidad y trabajar con mayor felicidad.

Para que nuestro proceso crezca de manera orgnica vamos a tratar a este

backlog de la misma manera que al de producto: sus tems estarn ordenadossegn prioridad. La misma estar dada por el retorno de inversin de cada unode sus tems. En este caso la valoracin es mucho ms abstracta que en elproducto: el valor est dado por cunta productividad, calidad y felicidadestimamos obtener al remover el impedimento, mientras que su costo ser unaamalgama del costo monetario (ej: el servidor es lento, hay que comprar unonuevo), humano (ej: la reuniones son monopolizadas siempre por la mismapersona) y/o polticos (ej: convencer a un gerente que deje de dar rdenes de

manera directa a los miembros del equipo).

CMOHemos visto hasta ahora al sujeto y al objeto: es hora de describir el

predicado. En esta seccin vamos a presentar la dinmica, el flujo que tiene unproyecto que utiliza el framework.

Ciclos de feedbackLa dinmica de un proyecto Scrum puede resumirse a grandes rasgos como

una serie de iteraciones durante las cuales se irn desarrollando orgnicamentetanto producto como proceso. Cada iteracin se asemejar a los saltos querealiz Hans para poder cruzar el ro. Decido hacia dnde saltar, salto, levanto lacabeza y decido: estoy saltando rumbo hacia la visin o debo virar? lamanera de saltar ha sido la ptima o debo cambiarla (ej: pruebo saltar con


28/38

ambos pies en vez de dar un paso largo)? Para poder tomar la decisin de virary/o modificar la manera de saltar necesito informacin, que provendr de larevisin de lo hecho recientemente. La duracin de los distintos ciclos defeedback representar los lmites que procurarn encauzar el caos sin cercenar

la creatividad. ProductoComo vimos anteriormente, el desarrollo del producto se dividir en dos

perspectivas complementarias: la estrategia y la tctica.

EstrategiaEl ciclo de feedback estratgico ser el Sprint o iteracin. Durante el mismo el

Equipo de Desarrollo procurar convertir el Backlog Comprometido en unincremento del producto que refleje los PBIs comprometidos. El Backlog

Comprometido quedar sellado durante la duracin del Sprint. Esto es, no sepodrn agregar, quitar o modificar PBIs durante la iteracin. Cul es la ideadetrs del sellado? Encauzar el caos estratgico. De esto se deduce que laduracin del Sprint, si bien podr variar de iteracin a iteracin, no podr variardurante la ejecucin del mismo. Cunto dura un Sprint? No se encuentraespecificado en Scrum, por lo que cada equipo encontrar su propia cadencia,seguramente mediante prueba y error.

El ciclo estratgico comenzar en la reunin de Planificacin Estratgica y

concluir en el Review o Revisin, prcticamente sobre el final de la iteracin. Planificacin EstratgicaLa reunin de planificacin estratgica tiene como principal objetivo que el

equipo de desarrollo se comprometa a la porcin del backlog ms prioritaria quequepa dentro de su capacidad estimada de trabajo para este Sprint.

RevisinLa Reunin de Revisin tiene lugar sobre el final del Sprint. El objetivo

principal de la misma ser que el Product Owner acepte o rechace, de manerabinaria, los distintos PBIs que el equipo haya desarrollado.

TcticaEl ciclo de feedback tctico ser mucho ms corto que el estratgico: ningn

plan resiste el contacto con el enemigo. En la tctica se ver reflejado el cmo:


29/38

las tareas que realizar el equipo de desarrollo durante el Sprint para construir elincremento del producto correspondiente al backlog comprometido.

Planificacin TcticaInmediatamente despus de la reunin de planificacin estratgica el equipo

de desarrollo se reunir para elaborar su plan inicial. Un primer esbozo de laserie de tareas que sern necesarias para desarrollar los PBIs comprometidos.

Reunin Diaria de Replanificacin TcticaLa tctica nunca se sella: en cualquier momento del da el equipo tiene la

potestad de actualizarla. Sin embargo, existe un momento bien definido en elcual el equipo de desarrollo se rene con el nico objetivo de inspeccionar yadaptar la tctica: asignacin, definicin y actualizacin del estado de las tareasque conforman el sprint backlog. Esta reunin suele llamarse Daily Meeting,

Scrum diario, Standup Meeting entre otras variaciones.

ProcesoEn Scrum partimos de una premisa fundamental: encontrar el mejor proceso

posible para que un equipo auto-organizado desarrolle un producto complejo esun proyecto complejo en si mismo. Por ende en Scrum aplicaremos las mismasideas que utilizamos para desarrollar un producto para construir el mejor procesoposible.

RetrospectivaLa retrospectiva es el corazn que le da vida a un proyecto que utiliza Scrum.! ! ! !Brjulas, rboles y dolores

TANTOS PEROS

Escucho, leo y hasta tengo pesadillas con la misma pregunta: "Estoyhaciendo Scrum o no?" En trminos generales los coaches, entrenadores yviejos lobos de mar tienen una respuesta clara y concisa: "Si sigues todas lasreglas del framework la respuesta es 's'. Si no, lo siento pero no". La lgicadetrs de este razonamiento tiene mucho sentido: Scrum es una pequeo peropoderoso motorcito que no alcanzar su objetivo si lo customizamos.


30/38

A partir de esta definicin harto simple, Eric Gunnerson acu hace ya aosen 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 estamos usando Scrum! Eso s, los sprints varan entre unasemana y tres meses, segn lo decida el Product Owner"

Esto de hacer Scrum es genial! Es una verdadera lstima que los dailymeetings duren casi una hora"

Etc, etc, etc

Siguiendo con esta lnea de pensamiento existe una clara forma de comenzartu camino con Scrum: sigue todas las reglas desde el primer da sin

cuestionarlas. El motorcito va a hacer su trabajo, iluminando el camino quetenemos por delante. Sin motor no hay luz.

EL ARCOIRIS QUE GOTEA

Scrum es una excelente manera de tratar con una organizacin disfuncional,pero no tiene sentido imaginarse una organizacin que no funciona en absoluto.

Al comenzar su utilizacin de Scrum las compaas tienen un cierto modo de

trabajo que, mal que mal, funciona. Si no, no habra organizacin. Cmohacemos entonces para utilizar Scrum sin despreciar ni desperdiciar un procesoque, aunque sea a duras penas, entrega resultados. Los cambios radicalesraramente funcionan: las dietas son un excelente ejemplo. De gordo a flaco agordo en, digamos, semanas. Tal vez poner en duda el enfoque del ScrumPerosirva 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 entrminos de un cielo despejado y colinas alfombradas de csped, no estamoscompletamente a ciegas. Imaginemos una escena montaosa, gris, nublada.Deprimente pero transitable. Qu significa Scrum dentro de esta topografaapocalptica? Un hermoso y brillante arcoiris. Al final del arcoiris, por supuesto,se encuentra el caldero repleto de monedas de oro. Nunca ha llegado ni jamsllegar al caldero, pero este arco iris es muy especial: acaba de ser pintado ytodava gotea monedas doradas. Existe un camino repleto de oro. Repleto. Eso


31/38

s, el sendero no est ni marcado ni es sencillo. Pendientes que trepar,desfiladeros riesgosos y precipicios que saltar. Scrum es, ni ms ni menos, tubrjula. El norte es, claro est, el final del arcoiris. Nunca llegars al final perosabes que vale la pena caminar. Eso s, ser una ardua caminata.

Impedimentos. Muchos, muchos impedimentos.

SINTETE ORGULLOSO DE ESE BROTE DE SCRUM

Tu adopcin de Scrum es un viaje nico, irrepetible. Si la vemos comoproyecto es sin dudas uno enormemente complejo. El enfoque que tomaremoscopiar a la naturaleza: crecimiento orgnico. Nuevamente plantaremos ycuidaremos de un rbol, nuestro rbol de Scrum. El ScrumMaster (coach Scrumo como querramos llarmarlo) es la semilla de este rbol y las retrospectivassern el agua y el sol. El terreno en el que este rbol crecer es nico, distintode cualquier otro, irrepetible. Con solamente tener un coach y hacerretrospectivas estoy haciendo Scrum? Yo creo que s. En mi opinin Scrum noes lo mismo que el framework Scrum. Scrum es el rbol y hay rbol en cuantohaya un brote que ve la luz del sol.

Cmo se vern sus primeras races, ramas y hojas? Recordemos en quconsiste una retrospectiva: el ScrumMaster, actuando como facilitador de lareunin, ayuda al equipo para que reconozca sus dolores ms agudos. La gran

mayora de esos dolores han estado all por tanto tiempo que ya nadie losrecuerde. La inercia es como la anestesia: la mente nos permite sobrevivirsimplemente negando la realidad.

El equipo ha aceptado, en voz alta, que tiene problemas. Graves. Lossntomas emergieron. Ahora es momento de llegar a la causa raz. A laenfermedad. Como lo hara un mdico clnico, el coach ayuda al equipo,preguntando con el fin de generar un dilogo exploratorio, a que ellos mismoslleguen al problema que causa el dolor. Una vez que alguien admite tener un

problema su perspectiva del mismo cambia indefectiblemente. Este es elmomento justo para cambiar el proceso: el equipo est sediento de curas. Estlisto para probar lo que el mdico recomiende. Sobre todo si la propuesta nosolo parece tener sentido, sino que tampoco representa tomar un gran riesgo.

Supongamos que un equipo ha estado trabajando en un proyecto durantemeses. Tal vez trabajan en una consultora. Tal vez es un equipo pequeo. Tal


32/38

vez su jefe es comprensivo o desptico. Tal vez tengan un sueldo altsimo. Noimporta el escenario: existen dolores. Tal vez el dolor ms agudo hoy es laambigedad y contradicciones que poseen los requerimientos. La causa pareceser que el equipo acta en respuesta al grito ms histrico que reciban desde el

exterior, sea del gerente de marketing o del auditor externo. El problema estsobre la mesa y el coach propone un pequesimo cambio en el proceso: unmiembro del equipo intentar convertirse en el nico punto de entrada paracualquier nuevo requerimiento. Probemos esto durante dos semanas. Si nofunciona descartamos la propuesta, al menos por ahora. La nueva estrategiaest bien clara y ha sido abrazada por el equipo. Lo intentarn por unassemanas y seguramente funcionar. La plantita de Scrum ha crecido un poco:ahora posee races, hojas y un tronquito que posee una pequesima porcin delframework llamada Product Owner.

Luego de dos semanas el equipo vuelve a reunirse con el coach. Funcion.Las cosas estn un poco, solamente un poco mejor que antes. No fue sencillo:varios stakeholders montaron en clera al escuchar una pregunta en vez de un"s". Pero funcion. Ahora es tiempo de reflexionar, explorar, diagnosticar. Otravez. El dolor ms agudo es ahora que algunas tareas nunca se hacen porquetodos creen que alguien ya las hizo. En la raz del dolor hay un problema decomunicacin. El coach propone: juntarse durante 15 minutos dos veces a lasemana, con el objetivo de enterarse qu estn haciendo el resto de los

integrantes del equipo. Suena razonable. Lo prueban y funciona. El rbol siguicreciendo. Esta pequea rama ahora tiene una reunin se parece, solamente unpoco, a algo llamado Daily Meeting, que forma parte del framework Scrum. Y elrbol seguir creciendo siempre y cuando el coach siga regando la planta.

El rbol crece como resultado de la paulatina facilitacin llevada a cabo por elcoach. Semana a semana el facilitador ayuda a que el equipo responda unapregunta simple: qu cambiar y por qu. A este proceso lo llamamos facilitacinguiada por el dolor (PDF: Pain-driven facilitation). El dolor no es infligido sino

detectado y expuesto a la luz. Y al fin y al cabo Scrum es bsicamente eso.

EL DESAFO DEL TRANSPLANTE

Y qu hacemos entonces con el dedo acusador del ScruPero? Si frenamospara reconsiderar a cada implementacin de Scrum como un proyecto


33/38

complejsimo en si mismo, utilizar el framework desde el da cero es equivalentea transplantar un arbolito del invernadero de Scrum a nuestra realidad.Transplantar a veces funcionay a veces simplemente no. Y cuando nofunciona, el joven rbol parece florecer durante cierto tiempo mientras por dentro

no hace ms que resecarse. El rbol muere. Lentamente. Y cuando un rbolmuere solo queda la corteza, o lo que es lo mismo en este caso, la ceremoniaque implica el framework. Roles y reuniones, simples nombres y ceremonias sinsentido. Hasta que un da sopla un fuerte viento y el rbol cae. Tal vez porquelas mtricas a fin de ao muestran una baja en la productividad, tal vez porquealguien se harta por fin de tener reuniones diarias de horas y horas. Seabandona Scrum. Fue una decepcin ms.

Esa nebulosa llamada esprituDE LEYES Y LIBROS DE ARENA

Cmo toma decisiones un juez? La ley escrita es general, abstracta.Loscasos particulares, el contexto y otros elementos subjetivos no suelen estarconsiderados en el texto de la misma. Por qu no es entonces trivial ser unbuen juez? Porque es necesario interpretar la ley. Qu han usado los jueces

durante siglos como base de sus interpretaciones? Jurisprudencia y espritu.Ejemplos e intuicin. Y Scrum qu?

Scrum es simple pero difcil. Por qu? Porque su definicin es clara yconcisa, pero a la hora de utilizar esa definicin es necesario interpretarlodependiendo del contexto en el que nos encontremos. La definicin de Scrum esincompleta a propsito. Tenemos a su vez el equivalente a la jurisprudencia en elmundo de Scrum: los casos de estudio y las buenas prcticas (ej: User Stories)nos han ayudado durante aos a perfeccionar nuestra prctica. Pero el esprituha quedado sistemticamente apartado de la discusin. Al menos no ha tenido elrol eminente y explcito que estime merece tener en la comunidad. La preguntaque resta hacer es entonces: Puede ser descrito el espritu?

PREGUNTA, PRUEBA, PREGUNTA, PRUEBA"Una manera de interpretar el significado de la pregunta 'Cmo?' es

considerarla una expresin de nuestro deseo de controlar y predecir. Es


34/38

claramente una pregunta atractiva. Creemos que hay control y

predictibilidad en la especializacin, el conocimiento y la certeza de hacer

la cosas del modo correcto. No a nuestro modo, no de algn modo, pero

del modo correcto. Creemos que existe una forma correcta, que alguien

conoce cul es y nuestro trabajo es encontrarlo. El problema resulta ser

que el mundo conspira junto a esta ilusin al intentar vendernos da a da

la respuesta. Preguntamos 'Cmo?' y el mundo responde 'As'."

"The answer to How is Yes" (pgina 6) - Peter Block - Barrett

Kohler

Definamosproceso como la manera en la que trabajamos aqu. Tu procesopuede ser catico, predefinido, emprico o aleatorio, pero siempre tendrs uno.Nosotros los trabajadores del conocimiento tenemos la necesidad inercial de

preguntar "Cmo?". Nada de exploracin para m: quiero una respuesta precisay definitiva para mis preguntas. Ese tipo de procesos tiene un nombre:metodologa. Una metodologa no es ms que un gran libro que tiene lasrespuestas para las preguntas "Cmo?", "Quin?", "Puedo?", "Cundo?",etc. Por eso no podemos afirmar que Scrum sea una metodologa, sino ms bienun marco de trabajo. Un marco que nos ayudar a tomarle cario a la arduacaminata que nos espera al ir definiendo proceso al andar. Por suerte Scrum nosayuda aportando ms preguntas que respuestas. Porque son las preguntas, alfin y al cabo, las que hacen que del trabajo del conocimiento un desafo

fascinante.

DE QUE HABLAMOS CUANDO HABLAMOS DE ESPRITUEl espritu de la ley es la intencin que los legisladores tenan en mente al

momento de redactarla. Por qu no est all mismo en el texto, expresada enpalabras? Simplemente porque a menudo las palabras nublan el entendimientocon su inherente ambigedad. Los legisladores prefieren un lenguaje simple,abstracto al momento de la redaccin, para permitir una posterior interpretacin

por parte de los magistrados. Los creadores de Scrum tenan muchas ideas,valores, principios, prcticas, nociones, preferencias cuando esbozaron elframework. Esos conceptos han evolucionado con el correr de los aos y lapropia experiencia de literalmente decenas de miles de practicantes. El espritude la ley evoluciona con el tiempo y esto mismo ha ocurrido con el espritu deScrum. Los ms experimentados con Scrum dividen a sus usuarios entre


35/38

aquellos que "lo entienden" y los que no. Limpiemos la bruma elitista que estdetrs del "lo". Hablemos de los conceptos y sus relaciones. Discutamos,aunque ms no sea por escrito.

SAVIAEn el captulo previo describimos cada implementacin de Scrum como un

rbol. A fin de chequear que un rbol se encuentra vivo podemos araar susuperficie y ver si detrs de la corteza divisamos o no un lquido verde y vivaz.Eso es, ni ms ni menos, savia. Es el espritu en el rbol de Scrum de un equipoen particular. Tenerla es tener un rbol sano. Haz Scrum sin saber por qu lohaces y tu rbol pronto se secar. Scrum ha pasado a ser intil por una simplerazn: ya no est ms all.

LA LISTA, LA NUBE, LOS NUTRIENTESNo hay un orden o tal vez s lo haya. Volemos a travs de la nube un poco

por aqu y otro poco por all. Tal vez un buen comienzo para la travesa sea lacomplejidad. Cmo solemos relacionarnos los trabajadores del conocimientocon la complejidad? Con menos humildad intelectual que la requerida parapoder admitir que tanto el encontrar el mejorproducto a construir como tallar elproceso ideal sern tareas complejas, muy complejas. El legado acadmicosuele imprimir un dejo omnipotente en nuestra manera de encarar los desafoslaborales. Scrum propone dejar de lado tanto racionalismo y abrazar elempirismo como filosofa de trabajo. Nada mejor que refrescarse un poconadando de vez en cuanto en el mar de la vulnerabilidad.

El error, piedra angular de este olvidado modelo de pensamiento, es, comopodemos aprender de las artes, la nica manera de llegar a un resultadocreativo. El error como tal siempre tendr un costo asociado: en dinero, amor,orgullo. Es hora de comenzar a considerar al error como inversin. Alequivocarnos aprendemos qu no debe hacerse. Pero tambin nos dimos la

suficiente libertad como para encontrar un diamante entre tanto carbn.

Qu riesgo acarrean las inversiones? Pueden, simplemente, salir mal. Paraello ser necesario edificar una dinmica de trabajo que resulte en un bajocosto del error. Veamos pues el andamiaje sobre el que se monta Scrum:planifico, ejecuto, inspecciono y adapto. Si queremos costo bajo debemos iterar


36/38

a gran velocidad. O lo que es lo mismo, necesitamos que nuestra manera detrabajo consista de ciclos de feedback cortos. Si me equivoco, quiero que sealo antes posible. Y necesito, claro est, transparencia a lo largo y a lo ancho demi proyecto. Un cortocircuito en la comunicacin y el feedback errneo llevar

a decisiones incorrectas.Pero an no terminamos con el error: para minimizar su costo debo a su vez

basar mi avance en el crecimiento orgnico. De otra forma cometer un errorimplicara haber puesto en riesgo el proyecto entero. Crecer orgnicamenteimplica brindar valor al cliente sin importar lo tormentoso que se vea el horizontedel proyecto. Pero por dnde comenzar a crecer si s que debo tolerar laincertidumbre? Nuestro objetivo es maximizar el retorno de inversin y nocumplir un mero plan. Por qu? ESTA SECCIN EST POR LA MITAD

! Confianza! Coraje! Colaboracin! Auto-organizacin! Horizontalidad! Dejar hacer! Compromiso! Disciplina! Ritmo sustentable! Relax! Esfuerzo! Balance! Liderazgo servil! Pragmatismo! Idealismo! Inconformismo! Puentes, no paredes! Yes, and! Excelencia tcnica! Simpleza! Perfecto = enemigo de lo bueno! Predictibilidad creciente! Aprendizaje continuo! Introspeccin! Incertidumbre! Paciencia! Tolerancia! Single-responsibility! Corto plazo


37/38

! Largo plazo! Priorizacin! WIP mnimo! Retorno de inversin! Espritu ldico! Libertad! Creatividad! Ensemble! Bricolage! ltimo momento responsable! Foco! Posposicin del compromiso! Novedades al instante! De lo concreto a lo abstracto! Ser explcito! Irradiacin de la informacin! Perspectiva nica! La respuesta a cmo es s! Neutralidad! Maleabilidad! Honestidad brutal! Perseverancia! Concreto => Abstracto! Kaizen

Creo que vi un lindo gatito

! Equilibrio! Control! Todo o nada! Perfeccin! Saber quin sabe! Lo que usted diga, seor! Mintindose al Solitario! Cundo llegamos?! El plan, el plan! Predictibilidad instantnea! Un rol es solamente un sombrero! Opresin? Qu opresin?! Dnde estn las minutas?! Un poco de 3M, pararse cada tanto y listo! Ahora van a pedir ms y msPor qu amo los lunes


38/38

ApndiceJurisprudencia de lo ms universal! La respuesta a cmo es s! User Stories! Taskboard! Grficos por Sprint! Grficos por proyecto! Clientes tozudos! Kanban! Prcticas de desarrollo de software

84799747 El Espiritu de Scrum

Documents

Transcript of 84799747 El Espiritu de Scrum