Por Un Scrum Popular:
Notas para una Revolución ágil

Tobias Mayer & Alan Cyment

La introducción de Tobias

Si reviso mi historia personal podría decirse que llegué al mundo del desarrollo de software relativamente tarde, si es que llegar tarde a algo en la vida tiene sentido como concepto. Tenía poco más de treinta años cuando usé una computadora por primera vez y, para ser sincero, lo hice porque no me quedó otra alternativa. Había empezado hacía poco tiempo en un nuevo trabajo ayudando a adolescentes en libertad condicional a desenvolverse mejor en la vida cotidiana y, con gran resignación, tuve que ponerme a transcribir su plan de estudios, registrar los progresos y enviar reportes. Saber utilizar hojas de cálculo y procesadores de texto era un prerrequisito para pasar la primera entrevista, lo que me dejó entre la espada y la pared. Las computadoras no solo no me interesaban, sino que de hecho me daban miedo. No les veía ningún atractivo, por lo que hacía lo posible por evitar cualquier tipo de contacto ¡Pero la necesidad tiene cara de hereje! Para mi sorpresa, una vez que aprendí lo básico, me venció la intriga y sentí la necesidad de indagar, de literalmente embarrarme las manos con pegajosos unos y ceros. Quería entender no solo como funcionaba ese monstruo binario, sino sobre todo dónde podía tocar para hacerlo caminar como yo quería. De niño abría cuanto aparato se pusiera en mi camino y no pude resistir la tentación.

Desarrollé mis primeros y humildes programas usando QBasic para DOS. A pesar de lo tosco del lenguaje descubrí, para mi total sorpresa, que apenas una partecita del desarrollo se trataba de matemática y lógica. Resultó ser que el resto del trabajo era poesía en estado puro. Semejante desborde de lirismo me atrapó. Un año más tarde ya estaba estudiando informática en la London South Bank University. Para 1999 ya estaba graduado y listo para arrancar con mi nueva profesión a todo vapor.

Pero se puede decir que antes tuve varias vidas. Trabajé en mundos tan disímiles como el de la construcción, el diseño gráfico o el teatro técnico. Como mencioné antes, también fui docente y facilitador del servicio social y del sistema de apoyo durante la libertad condicional. Desde este rol busqué incesantemente variantes novedosas que impulsen a grupos e individuos desamparados a buscar la superación personal, sin importar lo doloroso de su situación actual y pasada. Siento que esta última profesión se encuentra en las antípodas del desarrollo de software y, sin embargo, ha sido la experiencia que más me ha aportado a la hora de brindar consultoría ágil. Los adolescentes marginales y los desarrolladores que trabajan día tras día en corporaciones gigantes y opresivas resultaron tener muchas más similitudes que diferencias. Ambos tienen muchísimo para decir y, sin embargo, ninguno de ellos suele tener ni voz ni voto. Creo fervientemente que el verdadero reto para el coach ágil es lograr dar una voz a esa mayoría silenciosa, liberando así el espíritu creativo y tantas veces rebelde que habita en cada uno de los integrantes de ese olvidado colectivo, para luego hacerse a un lado y dejarlos recorrer su propio camino.

Durante mi tercer año en la universidad tuve la oportunidad de trabajar dentro de un grupo de investigación durante prácticamente doce meses. Allí llegué a la conclusión casi en seguida que un proyecto creativo que siga un proceso definido a priori va a generar mucho más sufrimiento y dolor que resultados y alegría. Mi tendencia natural siempre fue construir al tiempo que avanzo. Fue así como decidí focalizar mi trabajo de investigación en los procesos que seguimos para desarrollar software. Específicamente indagué qué ganamos y, sobre todo, qué perdimos en el mundo del software cuando se pasó de la anárquica cultura del hackeo a la otra que podríamos denominar corporativa, de espíritu controlador hasta la médula. No tardé en cruzarme con los primeros trabajos de Kent Beck sobre Extreme Programming (XP), donde pude reconocer un retorno a esos valores tan presentes entre los hackers de los años sesenta y setenta, pero con el ineludible agregado de la disciplina. Estaba fascinado. Pasarían varios años hasta poder poner estas ideas en práctica, pero la semilla estaba plantada. Las propuestas de Beck, tan minimalistas y enfocadas en las personas, generaban controversia y hasta horror en académicos y profesionales por igual. Éstos, en su gran mayoría, estaban agarrados con uñas y dientes a la idea de que lo que se necesitaba para mantener los resultados bajo control no era menos, sino mucho más proceso. Me encontré defendiendo una idea sobre la que no tenía mucho conocimiento frente a veteranos de mil batallas solo porque intuitivamente sentía que Beck había comprendido algo que la industria entera del software malinterpretaba cada día más.

Y Tobias descubrió la agilidad...

Mi graduación en 1999 coincidió con el deseo de mi familia de mudarnos de Londres a Palo Alto, en medio de Silicon Valley. Fue pura coincidencia que la familia de quien era mi esposa en esos tiempos viviera en la capital mundial de la industria del software. Nos mudamos por razones familiares, pero mi vida laboral se vio beneficiada: conseguí un puesto en una startup enfocada en el desarrollo de herramientas de pruebas para sitios web. Durante mis años como estudiante me había sentido atraído por el testing, por lo que me pareció un buen comienzo para mi nueva carrera profesional.

Aterrizar en el mundo del software recién a comienzos del siglo XXI me permitió ahorrarme una buena parte del sinsentido por el que tuvo que pasar una gran porción de los desarrolladores de mi generación durante los años ochenta y noventa. Trabajar en software significó durante muchos años tener que ir a la oficina de traje, cumplir con procesos definidos por algún superior, ser tratado como simple engranaje del negocio, susceptible de ser fácilmente eliminado y eventualmente reemplazado por generadores mecánicos de código o incluso por colegas del tercer mundo, a precios mucho más convenientes. Mientras tanto la agilidad ya había empezado a hacer su propio ruido. El primer artículo que describió los patrones que conforman scrum fue escrito en 1993 y Evo, la propuesta de Tom Gilb para gestión de proyectos de forma evolutiva, aunque poco practicada, era una idea que ya había cumplido más de diez años. Que quede claro que lejos estábamos de dejar de lado los modelos de “gestión científica” que nuestra industria había adoptado fanática aunque inexplicablemente. La fuente de inspiración en ese sentido fue (y sigue siendo para muchos) el trabajo que realizó sobre eficiencia en la industria durante el siglo XIX Frederick W. Taylor.

Mientras tanto la realidad decidió, como siempre, ser distinta de lo que quien deseaba controlarla esperaba. Internet, joven, gallarda, abrupta, desprejuiciada y, sobre todo, viralmente ubicua, irrumpió estruendosamente en nuestras vidas, erosionando brutalmente aquel modo de entender el trabajo. El concepto de rapidez se redefinía a un ritmo nunca antes visto. Silicon Valley era un verdadero manicomio a fines de los noventa. Como telón de fondo de semejante desquicio docenas de startups nacían y morían cada día, al ritmo alocado que marcaban las fluctuaciones en los bolsillos de dueños, inversionistas y curiosos con suerte. Cientos de personas se convirtieron en millonarios de la noche a la mañana, para luego ver desvanecer su flamante fortuna a los pocos meses. La compañía para la que yo trabajaba era un verdadero circo caótico, donde reinaba la microgestión y el control. Yo mientras tanto luchaba a brazo partido para poder implementar al menos alguna buena práctica de desarrollo y pruebas, pero la compulsión por mantener feliz al cliente echaba por tierra cualquier iniciativa que pusiese sobre la mesa calidad, sostenibilidad o incluso la salud de los trabajadores. La ironía, claro está, era que estábamos construyendo herramientas que se suponía iban a ayudar a otros a incrementar la calidad de su código ¿Pero quién prueba las herramientas que prueban al fin y al cabo?

Debo admitir que aprendí mucho sobre testing durante esa época. Dada la naturaleza de nuestro negocio asistí y hablé en las conferencias Quality Week de Europa y Estados Unidos. En uno de estos encuentros conocí a Lisa Crispin y Tip House, quienes me explicaron por primera vez la idea de “extreme testing”. El concepto despertó enormemente mi curiosidad y me retrotrajo a las épocas en las que había estudiado con gran interés extreme programming, lo que me llevó sin escalas de nuevo a las ideas de Kent Beck. Decidí comprar su último libro, pero muy a mi pesar durmió el sueño de los justos en un armario en la oficina durante el siguiente año. Si tengo que ser honesto, en los pocos ratos libres que tenía prefería dormir a leer.

La empresa para la que trabajaba se quedó sin un duro a fines de 2001. De un momento a otro dejó de pagar salarios y finalmente quebró en 2002. De la noche a la mañana me encontraba desocupado y sin dinero. Después de trabajar en la industria de la construcción nuevamente por un par de meses, conseguí un puesto temporal en Yahoo!, que con el tiempo devino en permanente.

Recién allí logré dedicar tiempo suficiente al libro de Beck y realmente implementar algunas de las ideas en nuestro grupo de trabajo. No se puede decir que hayamos sido un equipo XP, pero llegamos a implementar prácticas como la programación de a pares, refactoring frecuente, integración continua y pruebas unitarias automatizadas. Me uní al grupo de discusión agile-testing, que había sido creado en el año 2000 por Lisa Crispin y Brian Marick, donde aprendí mejores formas de probar software (donde “mejores” significa, sobre todo, más temprano en el proceso de desarrollo). En mi grupo quitamos la barrera que existía entre el desarrollador y el tester, para por fin trabajar como un único equipo. Llegamos tan lejos que hasta trabajábamos en parejas desarrollador-tester durante una buena parte del día. Fue algo. Fue significativo. Sabíamos que teníamos un largo camino por recorrer, pero qué demonios, disfrutábamos de nuestro trabajo.

En 2003 fui ascendido a una posición gerencial, como líder de un equipo de doce personas. Este cambio fue la gran oportunidad para continuar diseminando todo lo que habíamos aprendido hasta el momento. Mi propio gerente me dio gran libertad para explorar las distintas posibilidades que ofrecía el universo ágil y fue así como descubrí scrum. Su enfoque minimalista y centrado en el equipo fue para mí como una brisa de aire fresco. Scrum me permitió repensar la manera de liderar desde una perspectiva mucho más natural, intuitiva y, sorprendentemente, cercana a la forma en la que había conducido grupos en mis épocas de trabajo comunitario con jóvenes. Todo concordaba.

A comienzos de 2004 ya había terminado de leer los dos libros publicados para ese entonces sobre scrum y había participado en un curso llamado Certified ScrumMaster, dictado por Ken Schwaber y Kert Peterson. Durante los siguientes seis meses nuestro equipo practicó un scrum encubierto. Eso sí, sabíamos bien lo que hacíamos y qué queríamos lograr. Mantuvimos métricas bien detalladas sobre aspectos como cantidad de defectos, tiempos de entrega, cumplimiento de fechas o disponibilidad del sitio, con el objetivo de poder comparar los resultados obtenidos en proyectos anteriores. Estábamos confiados, pero la realidad nos sorprendió: éramos capaces de mostrar con números incontrastables una mejora de al menos un 500% en términos de calidad y time-to-market. Era sencillamente notable.

En enero de 2005, luego de que nos visitaran agilistas de renombre como Ken Schwaber, Jeff Sutherland y Mike Cohn, el sector de desarrollo de productos de Yahoo! decidió llevar adelante un proyecto piloto utilizando scrum en cinco grupos. En el marco de esta iniciativa logré cambiar de rol, para formar parte del recién formado equipo que estaría a cargo del proceso ágil. Éramos tres los responsables de llevar adelante los proyectos y brindar coaching a los equipos. Como suele suceder con este tipo de experimentos a bajo nivel en organizaciones enormes, nuestro éxito fue, por decirlo de alguna manera, modesto, pero sí fue claro que logramos sembrar las semillas del cambio, cuyos resultados pueden verse, ya florecidos, hoy en día.

Aquellos años con scrum

Decidí independizarme y dejar Yahoo! en agosto de 2005. Me había convertido por decisión propia en docente y coach de scrum y me encontraba listo para recorrer el mundo del trabajo de principio a fin. Luego de haber participado en el dictado de un par de cursos de Certified ScrumMaster junto a Ken Schwaber, me fue otorgado el estatus de Certified Scrum Trainer (CST) por la recientemente formada Scrum Alliance. En esa época éramos apenas 20 CST en todo el mundo, por lo que las oportunidades laborales abundaban. Creía firmemente en scrum como idea, pero siempre había tenido mi conflicto con el concepto de la certificación. En mi mente evocaba exactamente aquello de lo que queríamos huir: un modelo de liderazgo jerárquico, orientado al cumplimiento de meros procedimientos y precondiciones.

Esta disonancia me trajo problemas en mi nueva profesión desde el primer día, como bien lo marcan las constantes idas y venidas en mi relación histórica con la Scrum Alliance, el principal órgano que procura mantener scrum bajo control. En 2007 me fue quitado el estatus de CST debido a mi negativa a cumplir con nuevas reglamentaciones. A pedido de Ken Schwaber volví a ser Certified Scrum Trainer en 2008, pero esta vez tuve que atravesar un nuevo proceso de aplicación. Continué mi pelea constante contra la creciente burocracia que comenzaba a rodear los programas de certificación hasta que, para mi enorme sorpresa y luego de que fuera despedido el propio Ken Schwaber, el nuevo presidente del directorio me ofreció (sí, a mí y no a otro) el puesto de director creativo. Acepté entrar en la boca del lobo, con la esperanza de poder cambiar al monstruo desde dentro. Duré solamente ocho meses, hasta que en agosto de 2010 decidí renunciar no solo a mi rol, sino a todas mis certificaciones. Sencillamente no podía mantener mi integridad si continuaba teniendo y otorgando unas certificaciones hacia las cuales sentía un singular rechazo desde lo más profundo de mi corazón, dado que representaban de cuerpo entero un sistema completamente equivocado e hipócrita. Decidí publicar un texto a través del cual procuré fundamentar mi decisión, lo que trajo aparejado un aluvión de opiniones, tanto a favor como en contra.

Más allá de toda esta comedia de enredos, entre 2005 y 2012 trabajé como consultor, facilitador, coach y docente para diversas organizaciones que se encontraban en la búsqueda de métodos de trabajo más livianos y ágiles y decidieron que yo tenía la experiencia y el conocimiento como para ayudarlos en su camino. A finales de 2005 comencé a escribir sobre las ideas y experiencias que fui incorporando durante este increíble trayecto en los blogs Agile Thinking (“Pensamiento ágil”) primero y luego, cuando gané en audacia, en Agile Anarchy (“Anarquía ágil”). Esta colección de ensayos no es más que una selección de lo producido durante ese período.

La historia es circular, dicen algunos, y aquí estoy, es enero de 2013 y todo vuelve a empezar. Mientras estaba terminando los últimos detalles de este libro, Yahoo! volvió a contactarme y el círculo se cerró. Una vez dentro pude ver cómo durante estos ocho años ha ido brotando un profundo entendimiento y reconocimiento por la agilidad dentro de la organización. Todavía queda, tanto aquí en Yahoo! como en el resto de la industria, un larguísimo camino por recorrer hasta lograr la transformación cultural necesaria para que este nuevo modo de trabajo florezca y perdure, sobre todo luego de que los coaches y consultores terminan su trabajo y marchan hacia un nuevo cliente, pero tengo que admitir que es emocionante participar de un viaje tan transformador.

Los ensayos

Uno bloguea para el momento presente, tal vez con el objetivo de enterarse esa misma tarde qué siente el público sobre tal o cual idea. Ya lo dijo E.M. Forster: “¿Cómo voy a saber lo que pienso si no lo he dicho todavía?”. Algunas veces me sentí más que conforme con las ideas que lancé al aire, otras veces me sentí un tanto incómodo y otras simplemente ridículo. Durante el proceso de escribir y compartir gané en discernimiento y claridad a la hora de describir y transmitir todo aquello en lo que trabajo y creo. Los ensayos que les ofrezco en este libro son mis favoritos entre todos los textos que escribí y luego compartí entre 2005 y 2012. Una regla que me autoimpuse fue quedarme solamente con ideas y prácticas que todavía defiendo hoy en día. En algunos casos tuve que reformular substancialmente los conceptos y en otros, para mi gran sorpresa, quedaron prácticamente tal cual habían sido redactados en su momento.

Algunos de los ensayos contienen un mensaje pragmático y otros uno idealista. Algunos surgen de la experiencia, otros del pensamiento meramente abstracto. No hace falta leerlos en orden, sino que sugiero hacerlo según lo guíe el deseo y la necesidad. Su buen entendimiento requiere una mínima familiaridad con scrum y otros conceptos relacionados con la agilidad. En caso de no tener mucho conocimiento sobre el framework, recomiendo comenzar por el apéndice I (Scrum: un framework simple para problemas complejos).

Abrigo la secreta esperanza y el más profundo deseo de que, durante la lectura de este libro, el lector tenga alguna diminuta epifanía laica, que le sirva luego de inspiración para poder experimentar con estas ideas y prácticas en su propio trabajo. Desde una mirada menos ambiciosa deseo como mínimo que el lector encuentre ideas con las que esté en desacuerdo. Esto seguramente le ayude a clarificar su propio pensamiento, sea éste similar o profundamente distinto al que ofrecemos en este texto.

Tobias Mayer, Palo Alto, febrero de 2013

La introducción de Alan

Entre los tantos miedos que pueblan mi vida, el miedo al trabajo mecánico es sin duda uno de los que me acompaña hace ya décadas. Tal vez producto de mi ansiedad y neofilia, camino por el mundo buscando novedad, cambio y sorpresa. Cuando Tobias me preguntó si quería traducir The People’s Scrum al castellano, dudé y, lo admito, sufrí por un rato. En términos de mi camino en el mundo de la agilidad, me crié de la mano de Tobias y sus ideas. Durante varios años maduré conceptos (y por suerte descarté otros tantos) luego de revisarlos con él, escuchando, siempre sorprendido, sus ideas sobre el mundo. Ahora me tocaba devolver tanta generosidad, tantos años de consejos, realizando una tarea (¡el horror!) mecánica. Por suerte acepté. El favor me lo hice, sin duda, a mi mismo. Traducir este libro fue volver a mis fuentes. Una excursión trepidante a la mente de mi mentor, llena de energía, ideas y, por suerte, contradicciones.

Ahora, yo si fuera usted, lector inquieto, me estaría preguntando en este momento cómo demonios puede convertirse un trabajo aparentemente mecánico en una excursión trepidante. Exploremos, pues. Tobias, tal vez a sabiendas de mi pánico a la repetición, me aclaró que deseaba que yo sea coautor de esta versión ¿Intrigante, no? ¿Qué vendría a ser el coautor de una traducción? Ni él ni yo lo sabíamos, pero Hillary, nuestra editora, aceptó la caminata por terreno neblinoso y arrancamos a caminar. Propuse en seguida no pensar en esto como una traducción, sino como una “variación lingüística”. Me encantan los términos grandilocuentes.

Obertura

Como buen pastor de estos bueyes, creo firmemente que la acción precede al pensamiento. Hago, luego aprendo. O sea, empecé a traducir, sin rodeos, a fin de romper la inercia. Arrancar, cuando uno se encuentra en la más completa quietud, es todo. Hacía años que no escribía algo más que un mail. De repente, pomodoro a pomodoro, sentía ese dolorcito único en la mente, placentero, prometedor, propio de quien sale a correr al parque tras años de sofá y TV.

Traduje todos los ensayos con mucha menos necesidad de improvisar de la que me imaginaba originalmente. Eso sí, tenía muchas, muchas ganas de opinar. Me moría de ganas. Tobias opina cuando escribe y la opinión, si es interesante, casi siempre genera opinión. Fue así como se me ocurrió la idea del anexo tendencioso. Anexo implica una ligazón, una dependencia absoluta con un algo. Ese algo sería el ensayo. Luego, algo es tendencioso cuando se manifiesta con parcialidad hacia una cierta tendencia o idea. Quise volcar, sin un análisis demasiado sesudo ni pretendida neutralidad, lo que me venía a la mente después de leer a Tobias. Fue en ese momento cuando pensé, relajando por fin los músculos de la cara como antes de sonreír, que tenía un libro entre manos.

Allegro popolare

Solo faltaba una cosa: el título. Traté de explicarle tanto a Tobias como a Hillary las distintas acepciones que podía tener el people del título original. “Gente”, “pueblo” o “popular” pueden resonar muy distinto en cada individuo. A “El scrum de la gente”, tal vez traicionado por mi origen argentino, lo descarté rápidamente, harto del abuso mediático que suele hacerse de ese sustantivo. “El scrum del pueblo” ya estaba un poco mejor. Tobias disfrutaba de la connotación protopolítica del término, pero yo no veía la relación directa entre ambos conceptos. “Popular” es una palabra mucho más polisémica que las otras y eso me encantaba. Disfruto de los términos que se desdoblan en interpretaciones que a su vez encuentran sus respectivos caminos.

“Popular” puede perfectamente interpretarse como algo relativo al pueblo, así que el primer paso lo dábamos con el pie derecho. La idea de pueblo no estaba mal, pero le faltaba potencia. Entonces llega un nuevo significado: “propio de las clases sociales menos favorecidas”. Ya empezábamos a dar en el clavo. Conociendo a Tobias como lo conozco, su obsesión es la capa más baja del tejido corporativo. Lo que en Argentina llamaríamos “el laburante” (sí, lo pensé, “el scrum del laburante”, pero la idea es cruzar fronteras con estas ideas) constituye el objeto de sus propuestas. El trabajador raso es, desde mi punto de vista, una clase en sí misma ¿Desfavorecida? De eso se trata el libro al fin y al cabo.

La historia de las acepciones no termina ahí. Habrán notado ya como, a lo largo de todo el libro, nos referimos al framework en cuestión como “scrum”, claramente con minúscula ¿Ya les dije que me gustaba lo grandilocuente, no? La primera vez que leí el término escrito de este modo pensé, sin titubeos, que Tobias es nuestro humilde Prometeo. Listo, scrum es nuestro, Tobias lo robó. Lo único que necesité hacer fue avivar un poco el fuego.

Es cierto que “popular” tiene una última acepción que parecería tirar todo lo anterior por la borda. El scrum que buscamos no es aquel que persigue obtener popularidad, ser el más elegido, ganar la carrera. Pero nada se descarta, todo se aprovecha. Este significado nos da pie para darle una nueva vuelta al término y poder afirmar, abrazando plenamente las contradicciones y complejidades propias de las ideas que valen la pena, que el verdadero scrum popular será, al menos en un principio, eminentemente impopular.

Coda

No estoy seguro sobre qué tipo de lector se encontrará con estas líneas. No sé si será el experto o el recién llegado. No sé si será el escéptico o el defensor a ultranza. No sé si será oprimido u opresor. Lo único que espero es que al terminar de digerir este texto, ese lector imaginario pueda cerrar los ojos y sentir, con una tímida sonrisa, que el próximo lunes las cosas tendrán que cambiar, pase lo que pase.

Alan Cyment, Buenos Aires, Mayo de 2014

La gente:
Aquellos exploradores intrépidos

Me interesan muchísimo las personas y cómo interactúan éstas entre sí. Me fascinan las personas, tal vez más que cualquier otra cosa en este mundo. Me producen una enorme curiosidad las distintas maneras en las que elegimos vivir, lo que pensamos, lo que hacemos, las decisiones que tomamos. Al reflexionar sobre todo esto no puedo sino sentir curiosidad y desconcierto.

Las personas son rompecabezas listos para ser resueltos, a pesar de ser en esencia irresolubles. Compartimos nuestras historias de forma muy selectiva y con enorme cautela, sin nunca dejar de respetar las buenas costumbres sociales y culturales. Nos distribuimos por el espacio de forma sutil, para luego ocultarnos tras opacas máscaras.

¡Es tan pero tan difícil juntar todas las piezas en un sólo lugar, despegar las fachadas y poder ver la belleza que habita dentro de cada uno de nosotros! Nunca olvidemos, les pido de todo corazón, que, sin importar lo ardua que pueda ser, ésta debe ser una búsqueda incesante e inagotable.

Otra forma de pensar

Quisiera empezar con una imagen. Pinten en el aire una oficina donde reina la risa y la pasión. Donde todos, inspirados por un espíritu de camaradería, habitados por un clima de entusiasmo, propósito común y esperanza, trabajan en un ambiente donde se fomenta la escucha activa, la comunicación abierta y la colaboración a mansalva. Imaginen un ambiente laboral que nos recuerda al patio de la escuela, a la plaza del pueblo. Un espacio donde la innovación y las ideas disruptivas son una parte natural de cada interacción. Imaginen ser responsables de decidir sobre el ritmo, el espacio y la carga de trabajo. Imaginen tener como tarea entregar resultados concretos, de altísima calidad, de modo frecuente, a clientes relajados y profundamente deleitados.

Estoy convencido de que se puede convertir esta imagen en realidad usando un mecanismo simple y conocido, que les permitirá llegar desde su crudo presente hasta ese sitio donde les gustaría estar. Y no, a pesar del título del libro, ese mecanismo no se llama scrum. No hay framework, proceso o metodología que por sí solo permita alcanzar esta visión. La clave tampoco son los tan mentados líderes, cualquiera sea su color o tipo, aunque a varios nos encantaría sentarnos a esperar a que alguien nos tome de la mano y nos lleve con paso seguro hasta el final del arco iris. En el peor de los casos podríamos deshacernos de ellos y buscar nuevos que sí lo logren, ¿no? Bueno, no. Hay solo una persona, un método, una cosa que puede hacer realidad esta visión. Ese alguien eres tú, querido lector.

Más precisamente, la solución provendrá de la interacción entre tus distintas dimensiones: cuerpo, mente, corazón, espíritu y la relación con el prójimo. Al buen desarrollo de productos lo hacen realidad individuos felices y apasionados, participando de equipos motivados y llenos de energía.

¿Y en qué nos ayuda scrum?

Scrum te ofrece una mínima estructura y los límites para contener y guiar toda esa creatividad que suele estar tan celosamente guardada. Qué pena que tantos hayan entendido tan mal scrum: es un típico error conceptual afirmar que es una metodología similar a lean, six sigma, rapid application development o incluso kanban. Es cierto que se suele enseñar scrum desde esta perspectiva, pero entenderlo de ese modo es confundir, groseramente, la delicadeza de su esencia. Creo que se puede explicar certeramente scrum si se lo describe como un mero andamiaje. Un framework que ayuda a construir nuevos productos o a guiar proyectos complejos. No es, de hecho, una formula asegurada para tener éxito y, claro está, no es la próxima “bala de plata”. Scrum representa una huida, un escape consciente, premeditado y alegre, desde el mundo de los sistemas jerárquicos, basados en las órdenes y el control, hacia el universo paralelo que conforman la confianza y la autoorganización.

Scrum se basa fuertemente en la teoría de sistemas adaptativos complejos, una rama del pensamiento sistémico que trata de arrojar algo de luz sobre fenómenos tan caóticos e impredecibles como la economía o el medio ambiente. A estos sistemas nadie puede imponerles nada desde fuera, sino que por el contrario organización y estructura aparecen de manera emergente en forma de patrones. Al incorporar en cuerpo y alma el caos como concepto, scrum procura atacar los problemas complejos con una mezcla justa de inspecciones frecuentes, autoorganización y decisiones tomadas en el último momento posible.

Scrum consiste de unas pocas reglas y prácticas (resumidas en el apéndice I) que, aunque enormemente simples, son absolutamente esenciales. Cada regla y cada práctica es parte de un todo sinérgico, por lo que quitar una sola parte implicará destruir esa sinergia. Hacer las cosas a medias no va a lograr ni siquiera la mitad de los resultados. Al adherir a los lineamientos de scrum, y si se comprenden los principios subyacentes, lograremos que emerja el proceso que nuestro contexto requiere.

Ken Schwaber, cofundador de scrum, ha dicho que el framework sólo promete una cosa: ayudarte a fallar en treinta días o menos. Es todo. A medida que avancemos con el trabajo cotidiano emergerán por fin las disfuncionalidades organizacionales que habitaban nuestro día a día laboral. Eso sí, superarlas depende de ti, del individuo. Lo que scrum te ofrece es un espacio para ser humano. Para probar, fallar, reflexionar y volver a intentar. Comenzar a usar scrum será, no me cabe ninguna duda, el primer paso en el largo camino que implica desarrollar un ambiente de confianza, compromiso y libertad. Con el tiempo este tipo de entorno ayudará a liberar todo ese potencial humano latente que tanto nos cuesta aprovechar hoy en día, guiándote con paso seguro pero lento hacia la innovación y el tan anhelado éxito, cualquiera sea su definición.

Incluso, si lo pensamos bien, scrum ni receta ni promete nada de todo esto. Es simplemente una estructura que facilitará que ese tipo de entorno emerja, como una caña de bambú ayuda a una planta de tomate a dar frutos. Es la gente, son las personas (tú, tus compañeros de equipo y tus gerentes) quienes materializarán los cambios que dispararán nuevas actitudes y modos de pensar y entender. Una organización que se interese en serio en adoptar scrum deberá tener la paciencia suficiente para explorar y encontrar su propia forma de trabajo, contenida, eso sí, dentro de este simple marco. La gente que hace el trabajo será la que en definitiva descubra el conjunto más apropiado de prácticas que permita optimizar el retorno de inversión de la organización a la que pertenecen. La gente es quien va a crear un entorno de trabajo más feliz, no algún proceso aprendido por ahí.

No olviden entonces que scrum no es una metodología rígida, sino que evoluciona, se adapta. Del mismo modo que en el ajedrez, todo empieza con una serie de reglas simples y claras. Una vez entendidas esas reglas, una inmensidad de estrategias (scrum por ejemplo) es posible. Nunca hay que perder de vista que scrum es absolutamente dependiente del contexto: las necesidades de la organización serán las que orienten la implementación. No hay fórmula, ni prescripción, ni mucho menos una serie definida de pasos. Scrum no dice cómo hacer scrum.

22 de marzo de 2008

Anexo tendencioso: El tomate y la caña

Un ensayo impecable, del que me queda una imagen más que poderosa: la caña de bambú como sostén del verdadero valor, que se encuentra en las personas, no en el proceso, y el tomate, lleno de vida, que crece lenta y sostenidamente, siempre y cuando el suelo y el clima así lo permitan.

Mi único comentario o crítica quisiera realizarlo sobre la manera inflexible en la que Tobias describe al framework en sí mismo ¿Es realmente un juego que se juega a todo o nada? Existen, desde mi punto de vista, tres maneras de definir que uno está “haciendo scrum”. La manera tradicional, suscripta en este ensayo, presenta a scrum como una maquinaria minimalista, a la que no podemos quitar engranaje alguno si pretendemos que surta el efecto deseado. No hay negociación, estas son las reglas.

La rigidez produce, indefectiblemente, quiebres inconducentes. La reacción natural a este modelo que veo día a día en las organizaciones se resume en frases como “tomo lo mejor de cada enfoque” o “no soy un purista”. El quiebre nos lleva directamente al mundo de AcmeScrum, el segundo enfoque (a veces descrito como ScrumBut), que consiste en adaptar las reglas del framework, usualmente debido a que “Acme es diferente”. Esta adaptación suele realizarse de manera temerosa, cómoda y, ante todo, desde una mirada intelectualmente soberbia. Nos arrojamos a los brazos AcmeScrum porque decidimos, sin embarrarnos ni un poco, que tal o cual práctica de scrum no se corresponde con nuestra realidad. El principal problema que tiene este enfoque tan autocomplaciente es que, al tener una raíz intelectual, suele ser estático, nunca evoluciona. Así se debe hacer scrum en Acme y no tiene sentido ponerlo en duda.

El tercer enfoque, que disfruto llamándolo agilidad orgánica, es en extremo minimalista y, en una mirada fugaz y desatendida, se parece a la alternativa anterior. La agilidad orgánica requiere de solo dos elementos: retrospectivas sistemáticas (suelo recomendar un ritmo semanal) y un agente de cambio embebido en el espíritu de scrum. La agilidad en este caso brotará, semana a semana, como posible solución para los dolores que sepamos identificar. Si bien es cierto que aquí adaptamos el framework, este enfoque, al ser eminentemente empírico, parte de aceptar nuestra propia falibilidad luego de admirar ese tremendo precipicio que representa la complejidad de la realidad que nos rodea. La agilidad orgánica es líquida, fluye, nunca se detiene. Como tanto ser vivo, avanza o simplemente muere.

El corazón de scrum

Cuanto más enseño y brindo consultoría sobre scrum, más me convenzo de que el tablero físico es el corazón de scrum. Sin el tablero el equipo carece de centro, de foco. El tablero, si logramos comprender su verdadera esencia, se convierte en el hogar espiritual del equipo. Una especie de iglesia, si cabe la analogía. Los miembros del equipo se reúnen espontanea y ritualmente alrededor del tablero para discutir, pelear, innovar, alinearse, corregirse unos a otros, aprender y celebrar según corresponda.

El tablero (conocido también como taskboard), con sus fichas, Post-Its, cintas y banderas, inspira colaboración. Es visual, táctil y enorme. Se yergue como un gran comunicador de nuestro progreso y carácter. Proclama a los cuatro vientos quiénes somos como equipo. Es nuestra identidad. El tablero no calla la verdad, sino que la difunde: no tenemos miedo.

Al tablero se lo describe muchas veces como la máquina de café del nuevo paradigma. Este paralelo, aunque bien intencionado, no hace más que subestimar el poder y el significado del tablero. Claro, es un lugar donde nos encontramos a charlar. Pero no, no es un lugar donde nos quejamos, repetimos chismes ni vomitamos odios. El tablero es un sitio para regenerarse, para reconectar, para tomar aire. Representa avance, no huida.

Scrum es la antítesis de la mentalidad dividir-y-conquistar propia del cubículo corporativo. No necesitamos mesas de ping-pong y futbolines para calmarnos, para crear un equilibrio artificial entre la vida y el trabajo. No necesitamos que la diversión sea algo que solamente puede suceder al salir de la oficina. Trabajar puede y debe ser divertido. No necesitamos ratos al lado de la máquina de café y pausas fumando para poner en práctica una de las más profundas necesidades humanas, como lo es la conversación espontánea, honesta. En scrum vivimos conversando, todos los días, todo el día.

En scrum nos importa profundamente la gente, no su conocimiento. No hablamos en singular, sino siempre en plural. No soy ‘yo’, somos ‘nosotros’. Compartimos, aprendemos, mejoramos continuamente, interactuamos, colaboramos a pura pasión mientras crecemos como individuos. Formamos tribus, construimos comunidad. Los miembros de una tribu necesitan un sentido de pertenencia, una aventura en común. Las tribus necesitan lugares de encuentro, objetos sagrados, foco y pulso. En scrum queremos que florezca esta manera de vivir.

Para vivir plenamente scrum necesita un corazón y ese corazón es el tablero. Sin un tablero, scrum se ve y siente insípido, escuálido, debilucho. Se pierde todo dejo de foco y, sin un controlador externo como ser un coach que le insufle vida permanentemente, todo el esfuerzo que hemos puesto en juego se disolverá en el aire, para convertirse subrepticiamente y sin cambiar enteramente sus formas en el proceso disfuncional que vino a reemplazar. Sin corazón, scrum es impotente.

Una de las acciones más generosas que un scrum master puede hacer por su equipo y por la organización es crear transparencia, irradiar información. La transparencia nos permite ver los errores, para así poder decidir si queremos hacer algo al respecto. Podemos dejar de ser víctimas del proceso para convertirnos en guerreros del cambio.

Si los equipos realmente comienzan a adueñarse de sus tableros y descubren cómo utilizarlos para vivir a pleno el principio de transparencia, este humilde collage de papelitos y cinta se elevará por encima del injusto estatus que ha ganado de objeto meramente utilitario. Cada equipo es capaz de lograr que su tablero pase a ser no solo una herramienta útil sino también un objeto bello e inspirador. Creo sinceramente que ese es el lugar que el tablero merece ocupar. El corazón se nutre de amor.

3 de agosto de 2009

Anexo tendencioso: Ese otro palpitar

Si bien concuerdo con la importancia que tiene el tablero a la hora de moldear el imaginario del equipo, creo firmemente que el corazón de scrum está ubicado en otra parte de su ágil cuerpo. Mi sensación es que la retrospectiva es sin duda quien dará la energía que necesita un cambio de la magnitud que merece una implementación genuina de scrum. El tablero insufla un impulso inicial, colorido y terrenal. La retrospectiva, en cambio, permite seguir avanzando, explorando nuevos y peligrosos territorios, pase lo que pase, caiga quien caiga.

La experiencia me muestra que la importancia de la retrospectiva puede entenderse por oposición: cuando no la practicamos (o lo hacemos de formas poco efectivas) todo, en el fondo, sigue igual que antes. No hay reinvención y sin reinvención no hay vida.

El proceso, la forma en la que trabajamos, es un músculo. Hasta el más escéptico de los sedentarios entiende que los músculos, si no se los ejercita, se atrofian. Necesitamos esforzarnos, llevar sanamente al límite tendones y tensores, si queremos que nuestros músculos se mantengan, al menos, con la energía y tono que tienen hoy en día. Lo mismo, exactamente lo mismo, ocurre con nuestro proceso. Si dejamos que el tiempo y la indiferencia se ocupen de mantenerlo en forma, si pensamos que la mejor manera de trabajar ya fue decidida y no vale la pena retocarla, entonces vamos a acumular grasa subrepticia e indefectiblemente. Tal vez la aorta de nuestra organización tolere tanto lípido durante años y años. O tal vez no.

Autoorganización y anarquía

Se suele igualar por ahí autoorganización con anarquía, lo que ha producido que más de un gerente termine escapándole al concepto por miedo a perder el control. Jim Highsmith, un conocido agilista, ha respaldado esta idea, cuestionando la idea de la autoorganización e indicando que no solo es innecesaria, sino que incluso termina siendo perjudicial para el proceso de adopción ágil1. La sola idea me resulta trágica. La agilidad sin autoorganización es simplemente un proceso más, conducido unilateralmente por la gerencia como en los viejos tiempos, destinado por ende a mantener y alimentar el statu quo.

Tal vez la autoorganización sea caótica, hasta incluso anárquica. Genial, festejemos eso. El anarquismo no tiene por qué ser visto como algo negativo, especialmente si lo entendemos a partir de la siguiente definición, tomada del American Heritage College Dictionary: “Rechazo a todas las formas de autoridad y control coercitivas”2. Otros autores alejados de la piromanía siguen la misma línea de pensamiento, como L. Susan Brown, quien ayuda a clarificar el verdadero significado de la idea de este modo: “Si bien la imagen más conocida del anarquismo describe un movimiento antiestatal y violento, la propuesta es mucho más sutil que una simple oposición al poder estatal. Los anarquistas se oponen a la idea de que el poder y la dominación son necesarias para que exista una sociedad. Como alternativa proponen formas más cooperativas y horizontales de organización tanto social como política y económica.”

En el fondo de mi ser respira un convencido anarquista. Creo en la revolución ejecutada desde las bases como un camino posible para cambiar de raíz la manera en la que entendemos el desarrollo de software. Creo porque la gente que desarrolla el software es, para sorpresa de pocos y sin ninguna duda de mi parte, la más indicada para decidir cómo desarrollar ese software. A menos que encaren de forma autoorganizada los problemas inmensamente complejos que presenta esta disciplina, los resultados serán mediocres en términos de innovación y satisfacción de quien vaya a utilizarlo. Los clientes recibirán, si es que reciben algo, aquello que piden en vez de aquello que realmente necesitan.

Suelo utilizar mi mirada anarquista para animar a la gente a que desafíe toda autoridad innecesaria y así se replantee sus ideas más arraigadas. La experiencia me dice que este enfoque es tan poderoso como revitalizante. El anarquismo ha jugado un rol extremadamente útil en la historia de la democracia y creo que puede jugar un rol similar en el mundo ágil, así que no lo descartemos con tanta premura. Tanto Jesús de Nazaret como Gandhi fueron anarquistas. Ambos se enfrentaron diametralmente al statu quo y lograron cambios de una trascendencia incalculable. En la agilidad también deseamos provocar oleadas gigantes de cambios y reformas. Me pregunto si no tendremos algo que aprender de semejantes ejemplos.

Creo que cuando un agilista reconocido critica públicamente la autoorganización corremos el peligro de que aquellos que todavía se encuentran aferrados a la mentalidad corporativa se suban animadísimos al carro de la coerción, para así poder descartar de plano la idea y volver a sus hábitos de comando y control. Lo peor de todo es que seguro van a gritar a los cuatro vientos que habían estado en lo cierto desde un comienzo. Afirmar que la autoorganización no tiene sitio en el nuevo paradigma significa negar la existencia de esa multitud silenciosa que está literalmente haciendo milagros al sacudir cientos de corporaciones pacatas, mojigatas y moribundas, inyectándoles la pasión que traen consigo el compromiso y la autonomía. Tal vez se ha malentendido la autoorganización (de hecho creo que ocurre a menudo), pero esa no es una buena razón para descartarla de plano. Nuestra misión como comunicadores debería ser abrir mentes y corazones, no apaciguar ansiedades.

La autoorganización es un principio central en scrum. Creo que el concepto es esencial para poder cambiar la escala de valores que sostenemos y la manera en la que colaboramos entre los distintos niveles organizacionales quienes formamos la industria del software.

La autoorganización que funciona no deja de lado al liderazgo. Eso sí, el tipo de líder que un equipo necesita surgirá como producto de la sabiduría colectiva y nunca debería ser impuesto. Aquellos que no forman parte del equipo jamás serán los más indicados para determinar lo que necesita el grupo. Los equipos en los que funciona la autoorganización solicitarán líderes cuando los necesiten. Lo he visto funcionar y es absolutamente genial.

13 de septiembre de 2007

Anexo tendencioso: un punto sensible

Si bien estoy de acuerdo con prácticamente todo lo expresado en el ensayo, considero la reacción de Tobias al post de Highsmith un poco exagerada. Es cierto que este anexo tiene un ánimo apaciguador que podría leerse incluso como reaccionario, pero toca, aún de modo un poco gris a mi gusto, un tema sobre el que falta reflexión en la comunidad, como es la cuestión de los límites y el caos.

Así como scrum no debe interpretarse como el exacto opuesto a aquello que desea reemplazar, quisiera ubicarme con respecto a este ensayo a medio camino entre ambos autores. He presenciado implementaciones de scrum donde los equipos han pasado bruscamente de un modelo fuertemente jerárquico y controlador a una falta total de reglas y no me gustó lo que vi. Desmotivación, desconcierto, angustia y clientes descontentos durante meses pintaron un cuadro desolador.

Creo que pensar en términos de encender o apagar conceptos como la autoorganización genera polarizaciones que poco ayudan a que los equipos encuentren el sendero de la satisfacción. Scrum es en mi opinión no solo un destino inalcanzable pero motivador, sino sobre todo un sendero arduo pero disfrutable. Para recorrer ese sendero podemos visualizar diales, sintonizadores de distintas prácticas o principios, que iremos moviendo suave y juiciosamente, con el objetivo claro y con mucha paciencia. Hagamos una retrospectiva, quitemos algunos límites y experimentemos ¿Mejor? Entonces quitemos unos límites más ¿Demasiado caos? Probemos mover otro dial entonces. Ya llegará el momento de liberar ese aspecto.

Anexo tendencioso: el discreto encanto de la propia contradicción

“Este equipo no está listo para autoorganizarse” ¿Cuántas veces habré escuchado esta frase provenir del rostro autosuficiente de un gerente dispuesto a quedarse con la porción de scrum que más le conviene? Para que surta efecto la autoorganización debería entenderse más como generador que como destino. Para ser comprendida, la autoorganización debe experimentarse en carne propia, para recién allí poder encontrar empíricamente cómo se manifiesta de manera conducente en cada ocasión. Nuestro brillante e impoluto intelecto no bastará jamás para comprender su alcance

Amigo gerente temeroso, seamos honestos. Lo que usted me quiere decir es, sin rodeos, que la libertad es una cosa muy bonita, pero dentro de estas paredes funciona y funcionará una oligarquía opaca y verticalista. Amigo gerente temeroso, le tengo una muy mala noticia: su sistema simplemente no funciona. Tal vez si tuviera una fábrica de embutidos. Tal vez si esa fuera la única fábrica de la ciudad. Tal vez ahí sí. Pero los tiempos cambian y usted también debe cambiar, aunque más no sea por su propio bien y el de su empresa.

Quien no comprenda que el mundo con el que interactuamos es tan complejo como impredecible, jamás entenderá que para encarar a duras penas tamaño desafío no queda más remedio que confiar genuinamente en las personas. Una pena para quien no lo pueda ver, un milagro por venir para los que sí.

¿Terapia de shock o compasión?

Jeff Sutherland y Scott Downey, en su trabajo conjunto como coaches de scrum en MySpace, han creado un estilo de implementación del framework que denominan “terapia de shock”3. Proclaman a diestra y siniestra que de este modo logran que los equipos se conviertan en “híperproductivos” al poco tiempo de haber arrancado con scrum.

Si bien hay mucho que aprender de su caso de estudio, hay algo en el enfoque que no deja de perturbarme. Los autores usan términos como “contundente” y “obligatorio” para describir su forma preferida de implementar scrum. El propio Jeff Sutherland ha utilizado el término “wishy-washy” (soso, aguado) para desvalorizar las implementaciones que no utilizan su enfoque. No es fácil oponerse públicamente al fundador de un movimiento, especialmente cuando la oferta se ve tan irresistible. Jeff Sutherland es un tipo brillante, repleto de experiencia y enormemente respetado, pero en este tema siento la necesidad de poner en duda su propuesta, que no deja de producirme escozor ¿Es realmente “híperproductividad” lo que estamos buscando? El término tiene una increíble forma de bala y encima plateada.

Siento que lo que Sutherland y Downey presentan es simplemente cumplimiento forzado de un proceso y no creo que scrum se parezca ni un poco a eso. Definitivamente no es lo que busco ni es la razón por la que me uní a esta comunidad ¿Qué pasó con el compromiso, la libertad de elección, la innovación, la colaboración? ¿Directamente descartamos toda esa familia de ideas, calificándolas de sosas y relegándolas al terrorífico mundo de lo sensiblero? ¿Qué implicaría tomar esa decisión?

Temo que el concepto de híperproductividad, representado en este caso por la terapia de shock, va a terminar aplastando aquellos valores esenciales como el goce, la pasión y esa sensación maravillosamente enriquecedora que produce la autoorganización alimentada por la confianza. Sería un síntoma más que preocupante.

Definitivamente no hago lo que hago en aras de la híperproductividad, sino que lo hago en pos de la libertad, el sentimiento de pertenencia y la imprescindible conciencia de uno mismo. Calculo que alguien podría argumentar que el enfoque propuesto por Downey, con el tiempo, podría dar como resultado equipos con poder y voluntad de utilizarlo. He escuchado este argumento antes, hace ya muchos años: la gente feliz no produce necesariamente buen software, pero seguro que el acto de hacer buen software produce gente feliz. La idea, al menos superficialmente, tiene lo suyo, pero no creí en ella en su momento y tampoco creo en ella ahora. Nunca le vi dar frutos y creo que es una solución temporal, cortoplacista. La gente en definitiva vale más que el cumplimiento de un proceso.

Yo creo, en el fondo de mi corazón, que el cambio, para que tenga un sentido y sea sostenible en el tiempo, debe comenzar en el individuo. El problema es que carezco de métricas que me respalden, mientras que Sutherland y Downey las tienen a montones. Mi instinto me dice que son métricas cuestionables, pero me cuesta encontrar un argumento coherente para poder pararme en la vereda de enfrente. Las métricas que miden el proceso son fáciles de obtener. Las que miden las verdaderas sensaciones y sentimientos de la gente son muchísimo más difíciles de decidir, medir e interpretar.

Tal vez esté horrorosamente equivocado, pero siento que no puedo dejar así como así que la terapia de shock sea la manera que los equipos adoptan de manera predeterminada para comenzar con scrum. La empatía y la compasión necesitan un abogado defensor y me encantaría poder cumplir ese rol.

El término “terapia de shock” tiene su origen en el campo de la psiquiatría. Si bien ha producido grandes mejoras en casos severos de depresión y tendencias suicidas, no ha sido tan exitoso en otras situaciones. No olvidemos que incluso se utilizó con escasos resultados entre los años cuarenta y los años ochenta para “curar” adictos a las drogas. Hoy en día prevalece un enfoque más paulatino y espiritual a la hora de tratar las distintas adicciones, que si bien toma más tiempo, produce una recuperación más efectiva, afectuosa y a largo plazo. Es al menos curioso que un enfoque tan pasado de moda sea visto con buenos ojos en el mundo del cambio organizacional, que en definitiva deseamos tenga como trasfondo un cambio en la forma de ver el mundo ¿Será la violencia la mejor forma de lograr que se produzca ese cambio? Lo dudo mucho.

Al menos a partir de lo que pude entender de la propuesta de Downey y Sutherland, no me siento para nada inclinado a emplear la terapia de shock como método de transformación, sino que prefiero buscar un enfoque más humano y menos mecanicista. El cambio que perseguimos es demasiado trascendental para el mundo de la tecnología como para dejarlo exclusivamente en manos del proceso.

15 de septiembre de 2008

Anexo tendencioso: la tentación de lo inhumano

Tobias da otra vez en el clavo. Llenamos libros, foros y conferencias con referencias a lo humano, pero la sola mención del prefijo híper- nos endulza el paladar, nos nubla la conciencia y nos hace retomar, casi sin darnos cuenta, maneras y valores de antaño. Creo que este ensayo es fundamental para entender por qué pensar en términos de ScrumButt4 tampoco es la solución. No hay caso, todo me hace volver al concepto de la adopción orgánica del framework. Trasplantar un proceso puede dar frutos en el corto plazo, pero no siempre da como resultado una huerta sostenible que logre proveernos alimento y sombra durante años.

Resulta interesante, al menos como juego mental arbitrario y tendencioso, pensar que el caso de estudio se basa en una implementación llevada a cabo en el sitio MySpace, ejemplo paradigmático de producto que cayó estrepitosamente en desgracia por falta de innovación en todos los frentes. El sitio no supo adaptarse a la evolución de sus usuarios, la competencia y la tecnología, mientras Twitter y Facebook no solo le arrebataban la corona del universo social online, sino que terminaron hundiéndolo a las profundidades de la ignominia en Alexa. Al presentar los beneficios de la terapia de shock, Downey habla de un aumento de la velocidad superior al 1650%. Impresionante en términos de eficiencia, aunque aparentemente poco eficaz. Lograr que los operarios pongan más y más carbón en la caldera para que el tren acelere de modo maniático rumbo al precipicio no siempre es la mejor estrategia.

Artesanos del software

Desde que comencé mi carrera como desarrollador de software me siento incómodo con la idea de que nuestra disciplina sea considerada una ingeniería5. Yo vivo la creación de software como una disciplina artística, que permite liberar mi potencial creativo, del mismo modo que otros se inclinan por la costura, la poesía o la pintura. Recientemente encontré claro eco de estas ideas en las palabras de Jared Spool, un conocido especialista en usabilidad, en el foro Agile Usability6:

Un tema que la comunidad de usabilidad y experiencia de usuario no está abordando es cuánto de artesanal tiene nuestra disciplina. En ella las proezas individuales triunfan sobre la sabiduría colectiva y los procesos. Seguimos pretendiendo que lo que practicamos es una ingeniería, pero desafortunadamente es un oficio en el que en definitiva se necesita del arte y la técnica del artesano para tener éxito. Este es el inmenso elefante en la sala sobre el que nadie quiere hablar7.

Al leer los comentarios de Spool decidí volver sobre los pasos de mi incomodidad y entender mejor sus causas.

Intuyo que allá por los años que dieron comienzo a la revolución informática, algunos pensaron que su papel era tan vital para la humanidad (¡de hecho lo era!) que necesitaron sentirse tan reconocidos como los diseñadores de puentes, caminos o máquinas. O tal vez sea más probable que aquellos provenientes del lado académico, o incluso aquellos que no hacían el trabajo pero sí se beneficiaban de sus frutos, eligieron esa denominación. Luego de leer el libro Hackers8, de Steven Levy, me inclino por la segunda opción.

Un resultado directo del uso de este término ha sido seguramente la incorporación de las denominadas “buenas prácticas de ingeniería”9, que llevaron, claro está, al intrincado mundo del desarrollo en cascada que tan bien conocemos. Mi conclusión es entonces que un intento equívoco de ubicar a la programación como una disciplina respetable, de encajarla en el mundo ingenieril en vez de entender su naturaleza artesanal, ha causado muchos de los problemas que los agilistas estamos tratando de arreglar aun hoy. Son puras conjeturas, por supuesto, pero tal vez no estén tan erradas.

Las distintas artesanías, por naturaleza, han sido emergentes y adaptativas, mientras que las ingenierías se han jactado siempre de promover la estabilidad y la previsibilidad en sus campos. Los artesanos inspeccionan y adaptan continuamente, refinan, colaboran, dialogan con sus clientes y promueven la socialización de sus habilidades y conocimientos. Estas cualidades son propias del término “artesano”. Los ingenieros, en cambio, requieren un enfoque más formal y definido a priori ¡Los puentes no emergen!

Mi esperanza es que, de aquí a veinte años, artesanos y artesanas del software de todo el mundo nos mirarán en retrospectiva y se reirán de nosotros y nuestra imperiosa necesidad de definir procesos, inventar métricas y, por último, imponer prácticas “ágiles” a un saber que, en verdad, en su esencia, siempre fue netamente ágil. Lamentablemente la amplia mayoría de aquellos que trabajaban en esa industria no lo sabían. Esta verdad nos miró durante años a los ojos, pero nuestra necesidad de orden y predictibilidad, sumada a la importancia exagerada que nos dimos a nosotros mismos como pioneros en una nueva disciplina, se interpusieron en nuestro camino, impidiéndonos ver hacia adelante con claridad.

Tal vez lo que sí valga la pena recordar sobre el movimiento ágil es que nos permitió reencontrarnos con nuestra humildad más íntima y sentirnos a gusto con ella. Al menos eso espero.

31 de diciembre de 2005

Anexo tendencioso: Humildad, divino tesoro

De la perspectiva que propone Tobias con respecto a la ya legendaria dicotomía “arte o ingeniería” quisiera quedarme con un concepto que debería convertirse en nuestra piedra angular, el origen de cada una de las acciones que toma un practicante ágil. Scrum nos parecerá obvio si y solo si logramos desarrollar una profunda humildad intelectual. La realidad, la gente, los mercados, los equipos, el ecosistema tecnológico y cualquier software mínimamente interesante son extremada e incomprensiblemente complejos. El paso al vacío que tenemos que dar, universitarios y autodidactas por igual, implica resignarnos, de una vez por todas, a no poder resolver el problema que tenemos en frente solo con nuestro razonamiento. Encerrados todos los expertos, por más brillantes y sabios que seamos, no lograremos delinear los casos de uso, las jerarquías de clases, la interfaz de usuario y el modelo de negocios que mejor resuelven la problemática que tenemos por delante.

Sin una buena dosis de humildad intelectual nos costará admitir que somos falibles. Si no damos la bienvenida con los brazos abiertos al error, si no experimentamos, no exploraremos. Si no exploramos, solo conoceremos nuestro vecindario. Se pueden hacer muchas cosas caminando por las calles que conocemos de memoria, sin tomar riesgo alguno, pero difícilmente el buen software se cuente entre ellas. Como dice el proverbio japonés, cáete siete veces, levántate ocho.

Los equipos distribuidos no son equipos

Muchos practicantes ágiles se encuentran abocados con alma y vida a buscar la mejor manera en la que scrum pueda llegar a funcionar en entornos distribuidos (generalmente offshore). Hay multitud de personas muy inteligentes redactando artículos y enviando propuestas sobre este tema a las principales conferencias ágiles y todas empiezan más o menos así: “Sabemos que trabajar juntos físicamente sería ideal, pero la realidad nos indica que...” Luego suelen proponer meros parches, soluciones lejanas del ideal para la incómoda pero real distribución de los miembros del equipo a lo largo y a lo ancho del planeta.

Siempre me ha parecido interesante cómo la frase “el mundo real” suele blandirse amenazadoramente frente al rostro perplejo del idealista: Sí, está muy bien afirmar que los equipos deberían trabajar juntos, pero eso no pasa en el mundo real. Parece ser como si nos olvidásemos que la realidad no es algo que se nos imponga. La realidad no aparece por generación espontánea, sino que la creamos con cada una de nuestras acciones. La frase “el mundo real” resuena en mis oídos como el viejo y conocido “y bueno, las cosas aquí son así”. Ambas deben ser confrontadas con una sana dosis de escepticismo y un aluvión de preguntas que empiecen con un mágico “¿por qué?”. Que hoy sea así no implica que mañana deba seguir igual.

Los equipos distribuidos no son equipos; como mucho puede decirse que son un grupo de personas que se comunican con frecuencia10. Pero comunicarse no es necesariamente colaborar. La relación que se establece entre los miembros de un grupo distribuido suele ser chata, fofa y fría. Un equipo distribuido no puede crear esa clase de energía desbordante que se desata a partir del contacto visual, de la carcajada espontánea o del mero contacto físico, desde una palmada hasta un abrazo fraternal. La colaboración genuina necesita de los cinco sentidos. No basta con una voz con ruido a fritura o un video pixelado y con demoras que desafían al más zen ¡Y no me hagan hablar del mail! Los equipos distribuidos necesitan indefectiblemente de coordinación y administración, por lo que nunca serán completamente autoorganizados. La diferencia de zonas horarias, con los consecuentes tiempos de respuesta interminables, ralentiza la conversación, pospone innecesariamente muchas decisiones y termina mutilando todo intento de agilidad. Los equipos distribuidos no podrán ser jamás verdaderamente ágiles, por lo que nos pido que por favor dejemos de hacernos los distraídos.

Propongo que nos detengamos por un segundo y, en lugar de seguir pensando que tenemos que ofrecerle scrum a cualquiera que nos lo pida, busquemos alternativas. Imaginen esto por un segundo: ¿qué pasaría si de repente todos los coaches de scrum rehusaran trabajar con las organizaciones que insisten en tener equipos distribuidos? La intuición me dice que esas compañías lo seguirían intentando sin éxito, hasta que varias de ellas terminen en la ruina. Estas compañías piden scrum precisamente porque tienen dificultades, pero rara vez están dispuestas a reinventarse para convertirse en ágiles. Lo quieren todo: proveedores baratos y grandes márgenes. Como lo veo yo no difieren mucho de las industrias que emplean niños en el tercer mundo. Tal vez tengamos que simplemente decir que no. Lo sentimos, pero no vamos a apoyar esta locura. Hacer encajar scrum en entornos como éstos puede hacerlos mantenerse a flote por un tiempo más, pero están condenados al fracaso. El modelo es horrible e indigno. Socava las relaciones humanas y es burlonamente abusivo. Y lo peor de todo es que desde un punto de vista puramente de negocios, simplemente no rinde.

Scrum promueve que nos equivoquemos rápido. Nuestro objetivo como agilistas debería ser acelerar el fracaso del modelo distribuido, no prolongar su agonía. Una vez que las organizaciones que sustentan este desafortunado modelo hayan pasado a mejor vida, podremos comenzar con el hermoso desafío que implica construir nuevos tipos de compañías, más flexibles, casi sin necesidad de gestión, creativas y modeladas sobre los verdaderos principios ágiles. Sí, ideales, no a medias tintas. Cuanto antes suceda, mejor será para todos nosotros. Hay muchos ejemplos de organizaciones que literalmente han abrazado la proximidad física de sus equipos, la autoorganización y la democracia, que poseen éxitos medibles para probar que esta estrategia sí da resultados. Menlo Innovations, la planta de General Electric en Durham, North Carolina y la compañía brasilera Semco aparecen como interesantísimos casos de estudio para entender mejor este enfoque, pero en definitiva lo que necesitamos es básicamente abrazar los principios y no simplemente copiar como niños lo que hizo alguien mucho más valiente que nosotros.

18 de julio de 2008

Anexo tendencioso: imágenes de una patología endémica

Como menciona Tobias en su nota al pie, resulta práctico dividir al mundo del desarrollo distribuido en dos grandes grupos antes de tratar de entender cómo encaja scrum en ese contexto. Por un lado están los grupos compuestos por desarrolladores comprometidos, usualmente talentosos, que por cosas de la vida viven en distintas zonas geográficas, pero desean trabajar juntos. El libro Remote, de Fried y Heinemeier Hansson, representa tanto un análisis como una verdadera celebración de este modo de trabajar, que tiene sus orígenes en los proyectos exitosos de código abierto. Podríamos bautizar este modo de trabajo como “distribuido comprometido”. Estos grupos de trabajo, a pesar de no compartir un mismo espacio físico de trabajo de forma diaria, pueden lograr una cohesión y sinergia simplemente notables. La distribución en este caso es una decisión de vida de cada uno de los miembros del equipo, que ha decidido ganar calidad de vida, compartiendo más tiempo con su familia, dedicando menos horas viajando al trabajo y más a sus pasiones.

En el otro extremo se encuentra la fábrica de software ubicada en un sitio donde los salarios son sensiblemente menores a los del cliente. El “distribuido industrial” puede parecerse al caso anterior a primera vista, pero existe, literalmente, un mundo de diferencia. La motivación para estar distribuidos no parte del individuo, que en el otro modelo persigue una mejor calidad de vida y colaborar con otros tan buenos como él, sino más bien del cliente, que desea un buen precio y poder comenzar un proyecto mañana mismo si es necesario. Los proyectos offshore, a los que conozco muy bien desde la perspectiva del proveedor, son un compendio de pesadillas dantescas, que se repiten una y otra vez, país a país, empresa a empresa.

Sea cual sea la situación particular, el pecado original lo comete siempre el cliente. Lo barato puede salir caro, piensan muchos primermundistas, y por ende es mejor sospechar del nuevo proveedor-bicoca, recelar a priori. El cliente de la fábrica offshore es desconfiado por naturaleza. Desde una probable soberbia originada en el prejuicio, pasando por el simple hecho de que en la mayoría de los casos jamás conocerá a su proveedor cara a cara, todo conspira para que rara vez exista un vínculo de confianza entre ambas partes. A partir de ahí, cualquier intento de construcción de equipo cruje.

El cliente desconfiado anhela retener el control, para lo cual apela a estrategias entendibles, aunque casi siempre contraproducentes. Un clásico de estas situaciones es el cliente que impone un “referente técnico”, “tester senior” o “arquitecto” como miembro del equipo. Esta persona, cuyo conocimiento es en un comienzo necesario, termina siendo un verdadero palo en...la rueda. “Presente” en todas las reuniones, transforma cualquier atisbo de agilidad en una verdadera farsa. Todos aquellos que pasaron por un escenario así deben recordar con poco cariño interminables retrospectivas en inglés, con una voz fritada que aparece cada tanto para preguntar qué quiso decir éste o aquel. La mayoría de los miembros del equipo suelen ser capaces de redactar un mail técnico en el idioma del bardo de Avon, pero están lejos de poder comunicarse en inglés con el nivel de entrega, sentimientos, análisis y verdad que requiere una retrospectiva efectiva. Y sin embargo el cliente desea ejercer control, asfixiando cualquier intento de hacer scrum de modo genuino. Más de un cliente lleva al paroxismo el oxímoron que representa scrum offshore al implantar un scrum master remoto. Concepto ridículo, infantil, paradójico desde su sola formulación.

Eso sí, las fábricas de software offshore son cómplices antes que víctimas de tanta perversión. Muchas veces para responder a un pedido de extrema productividad, sus trabajadores “siguen al sol”. El objetivo entonces será formar grupos de trabajo maximizando (¡no minimizando!) la diferencia horaria entre sus miembros. La configuración típica constituye a los analistas en un determinado huso horario, varios husos más tarde se encuentran los desarrolladores y en la franja que resta del globo estará el equipo de pruebas. La vuelta al mundo en una cascada taylorista. La lógica está en maximizar husos horarios, no canales de comunicación.

La intuición me dice que con el paso de los años los clientes que comiencen a definir el éxito de sus proyectos en términos de retorno de la inversión, basándose en una real evaluación del valor obtenido y no en la mera entrega de requerimientos en tiempo y forma, terminarán abandonando este modelo, con una notable excepción. Emergerán entre tanto desconcierto proveedores offshore de alta calidad, que habrán obtenido una enorme confianza a partir de un servicio impecable, que serán quienes encabezarán la revolución del offshoring: no solo delivery, sino tambien discovery. Product owner, scrum master y equipo, todos del lado del proveedor, quien realizará el desarrollo completo del producto, desde su concepción hasta la obtención de valor tangible. Eso sí sería ágil.

El Hombre Araña dice que...

Recientemente tuve el enorme privilegio de trabajar con una organización en el Reino Unido cuyos managers se toman bien en serio la incorporación de scrum y entienden que adoptarlo es mucho más que un mero remiendo. La gerencia entendió que va a tomar tiempo ver los resultados más patentes del uso de scrum y, tal vez esto sea lo más importante, incorporaron como propia la necesidad impostergable de confiar en sus equipos de desarrollo.

Compartí cinco días con 25 desarrolladores y testers comprometidos a trabajar tiempo completo conmigo. Pensé en lo significativo de la inversión y recordé un poco consternado esas tristes compañías en las que algún gerente me dijo algo así como “no podemos asumir el costo que representa que nuestros empleados tomen un curso durante dos días...hay muchísimo trabajo que hacer”. Me vino a la mente el cuento del leñador que ve que su sierra está desafilada, pero afirma resignado que está demasiado atareado cortando árboles como para frenar a afilarla. Por suerte esta gente con la que estaba trabajando era distinta.

Los equipos de esta compañía habían estado haciendo scrum durante unos dos o tres meses cuando yo aparecí. El único scrum master que tenían en aquel momento había tomado un taller introductorio que yo había cofacilitado ese mismo año. Los equipos habían logrado algunos avances interesantes durante la transición, pero habían encallado y pidieron la ayuda de un coach externo. Siempre aprecio cuando un grupo tiene la suficiente humildad e introspección como para reconocer que necesita apoyo. Me pregunto cuántas compañías no logran darse cuenta de esto y continúan peleando una batalla contra sus propios demonios para la que no tienen ni la armas ni el entrenamiento necesario. Scrum no es nada fácil: logra que los problemas emerjan casi con violencia y hace que apreciemos con claridad cuán repugnantes son. Muchas organizaciones van a hacer lo imposible por ocultar todo lo que sea desagradable a la vista y arrastrarse lastimosamente con una especie de “scrum híbrido” (¡¡alerta!!) que no ayuda a reconocer, y mucho menos ataca, las causas raíz de esos problemas. Otras compañías van a resolver abandonar scrum por completo y concluir, entre resignados y alegres, que “la agilidad no es para nosotros”. Felizmente, esta compañía británica había decidido avanzar con paso firme y enfrentarse a sus dificultades.

Los primeros dos días nos enfocamos en promover un entendimiento colectivo tanto de la filosofía como de las reglas que componen el framework. Había mucho escepticismo entre los empleados. No nos olvidemos que ésta fue una iniciativa que surgió desde la gerencia hacia los niveles inferiores y no a la inversa. Se podría decir que una buena parte de ese escepticismo era del sano (¡ganas de aprender!), pero había también del dañino. Aun así, la actitud general del grupo era positiva. Mi cofacilitador, Michael James, y yo habíamos avanzado considerablemente en crear un entendimiento compartido de las bases de scrum y de las sorprendentemente simples herramientas que suelen acompañar sus implementaciones, como el tablero físico, al que cada día considero más y más como un elemento clave de un equipo scrum que funciona a todo motor. Cuando se usa correctamente el tablero brinda foco y equilibrio a cualquier equipo.

Durante los últimos tres días el trabajo nos concentramos en mejorar la calidad del product backlog, identificar impedimentos a nivel organizacional y, tal vez lo más interesante, explorar los límites de la autoorganización. Como resultado los equipos se reestructuraron por completo y desarmaron un grupo de “control” que tenía como responsabilidad la toma de decisiones y la priorización, estimación y asignación de todo el trabajo por hacer. Las responsabilidades que recaían sobre este grupo se distribuyeron entre los equipos y los product owners. Tomar estas decisiones por ellos mismos creó una sensación tal de empoderamiento y libertad entre los miembros de equipo que hasta yo comencé a preocuparme. Sentí que corríamos un leve peligro de pasar a un estado de anarquía ¿Les habíamos dado tal vez demasiada libertad? ¿Demasiado poder? ¿Cómo iban a utilizarlo?

Recordé la famosa cita de El Hombre Araña: “con un gran poder viene una gran responsabilidad”. Los equipos tenían poder, eso seguro, ¿pero cuál era su responsabilidad? Esta pregunta nos condujo a una discusión sobre compromisos y obligaciones. El grupo decidió por consenso crear un estatuto compartido, en el cual los equipos expresarían su compromiso para con la organización. Hicimos este trabajo en pequeños equipos a lo largo de tres iteraciones, al final de las cuales los grupos compartían sus resultados con el resto del grupo, para luego repensar y adaptar sus propuestas en el siguiente ciclo. De este modo logramos utilizar una versión simplificada de scrum a escala: estábamos viviendo de acuerdo a nuestros principios. Al final de la tercera iteración el producto estaba listo. No era el producto perfecto, pero lo obtenido redundaba en una serie de acuerdos de trabajo con la que todos (incluyendo los escépticos) podían comprometerse durante los siguientes treinta días, cuando el grupo se reuniría nuevamente para revisar el documento. El estatuto se imprimiría en gran tamaño y se colgarían copias a lo largo de todo el edificio, para que todos lo tengan presente todo el tiempo.

Esta es una copia del resultado de esa actividad:

Estatuto del equipo

Framework: Nos comprometemos a respetar los principios ágiles, en la medida de nuestras posibilidades utilizando por completo el framework propuesto por scrum

Calidad: Nos comprometemos a poner foco en la calidad durante cada una de las etapas de la construcción de nuestros productos y a revisar y mejorar las técnicas que utilizamos para este propósito.

Gente: Somos profesionales y como tales tenemos la responsabilidad de respetarnos mutuamente, actuar de forma honesta, comunicarnos abiertamente y ayudar y buscar ayuda cuando corresponda.

Proceso: Nos comprometemos a definir en conjunto con la organización un proceso mínimo que guíe nuestras actividades durante los sprints, delegando las decisiones necesarias a los equipos para que cumplan con sus objetivos.

Crecimiento: Como individuos, nos comprometemos a incrementar, profundizar y compartir con el resto de la compañía todo nuestro conocimiento y experiencia.

Tengo que decir que quedé muy impresionado cuando vi este resultado. Lo primero que pensé luego de leerlo fue en lo genial que sería que tantísimas otras organizaciones generaran documentos similares. Al verlo me di cuenta que no es nada fácil encontrar empleados que se tomen una implementación de scrum iniciada desde la gerencia tan en serio y con semejante grado de dedicación.

Más allá de quién haya dado comienzo a este proceso, el trabajo que hicimos en conjunto permitió a los integrantes de los equipos expresar abiertamente de qué forma preferían trabajar y entender que, aunque les resultase difícil de creer en un comienzo, ellos tienen voz y voto para decidir sobre su destino. La transformación organizacional es difícil, pero tiene que empezar en algún lado y creo fervientemente que cuanto más bajo sea el nivel jerárquico de quienes motorizan el cambio, más potente será el proceso.

2 de agosto de 2006

Desenterrando impedimentos haciendo incluso menos

La comunicación de los impedimentos es todo un desafío para quienes comienzan con scrum. Es muy común ver cómo les cuesta a los equipos novatos articular los problemas que tienen, así como también se puede ver en el rostro confundido y ansioso de muchos scrum masters primerizos la lucha por encontrar las preguntas adecuadas que hagan que esos impedimentos vean la luz.

No creo que el camino sea concentrarse en hacer mejores preguntas, sino que me parece mucho más efectivo enfocarse en crear un ambiente de visibilidad y honestidad. La visualización del plan ayuda en ese sentido, pero no puede por sí sola. A veces necesitamos simplemente patear el tablero. O simplemente rediseñarlo.

En todos estos años me he cruzado con prácticas nefastas, pero si hay una que ha impedido sistemáticamente identificar impedimentos es estimar las tareas en horas y hacer que los miembros del equipo actualicen esa estimación en cada reunión. Varios fundamentalistas de scrum me han dirigido serias miradas reprobatorias cuando me escucharon hablar en contra de esta práctica. No le ven sentido a mi propuesta, pero sí que lo tiene. Un montón de sentido.

Hace ya algunos años recuerdo haber tomado el rol de scrum master de un equipo que había estado practicando scrum “siguiendo el libro” (según sus palabras). Todos sin excepción detestaban la reunión diaria, pero en particular expresaron su rechazo al proceso de actualización de las horas. Sentían que los estaban midiendo a un nivel prácticamente microscópico en vez de encomendarles el trabajo y listo. Pensaban que esta actividad era insultante y básicamente una pérdida de tiempo. Dado que soy un tipo que suele confiar más en la intuición que en las métricas, no me costó mucho ceder al pedido de abandonar esta rutina. Si bien hoy en día no está bien visto adaptar scrum11, allá por los primeros tiempos reinaba una cultura más experimental, tal vez más apegada al espíritu de “inspección y adaptación” propio del framework. Sea como sea, me pareció que todavía podía llamar scrum a lo que hacíamos, sobre todo si tenemos en cuenta que en la cultura de esa organización eso era importante.

Acordamos entre todos que no íbamos a estimar las tareas en horas, con la condición de que ninguna de ellas iba a superar el día de trabajo. Esto último resultó mucho más importante de lo que parece a primera vista. Lo que descubrimos a través de este cambio en nuestro proceso es que ahora, si una tarea no se había completado tras un día, esto indicaba casi con seguridad que existía un impedimento que se había omitido mencionar, o incluso reconocer como tal. Para los impedimentos tan minúsculos como “pensábamos que esa tarea era más fácil”, la solución era igual de sencilla: subdividir la tarea en menos tareas y comprometerse a realizar la primera de ellas para el día siguiente. Sin embargo, muchas veces esta técnica lograba que emergieran problemas mucho más graves.

Recuerdo un caso en el que los equipos estaban comenzando a retrasarse y un desarrollador había tenido una tarea en la columna de “trabajo en progreso” del tablero durante tres días. Luego de un día nos dijo que estaba casi lista, pero resultó ser un poco más grande de lo que había pensado. La marcamos con un punto rojo (lo que indica visualmente el bloqueo que tiene la tarea). Al terminar el segundo día dijo que no había tenido tiempo para terminarla, lo que causó sorpresa en todo el grupo ¿Qué lo había tenido ocupado? Resultó ser que ese desarrollador era llamado frecuentemente para arreglar bugs de otro proyecto, hecho que nunca antes se había discutido durante la reunión de planificación. Nadie en el equipo veía esto como un impedimento, dado que “aquí se trabaja así”. Claramente algo tenía que cambiar.

Este problema no habría emergido tan rápidamente de no ser por la restricción de la duración de las tareas a un día. Medir las cosas a un gran nivel de detalle, a pesar de tener la intención de crear visibilidad, había terminado ocultando información determinante.

También me viene a la memoria otro equipo con el que trabajé, esta vez con una herramienta electrónica que permitía registrar tareas. Los desarrolladores se anotaban horas asociadas a tareas, sin importar si habían estado concentrados en ellas o no. Les gustaba ver cómo bajaba a ritmo constante el burndown chart y no se animaban a decir delante del resto que las tareas eran más grandes de lo previsto. Para el final del sprint a casi todas las tareas les quedaba más o menos una hora pendiente. Casi no había tareas finalizadas y, por supuesto, ni una historia de usuario podía considerarse hecha. Esto terminó de convencerme de la necesidad de medir resultados binariamente. Una tarea está hecha por completo o no lo está. Una tarea a la que le falta una hora no está hecha.

Dejar de medir avances parciales en tareas e historias y concentrarse únicamente en medir trabajo terminado ayudó a este equipo a tener una mejor idea del verdadero volumen de trabajo del que eran capaces. Simultáneamente logramos tener un ambiente de trabajo donde aumentó la honestidad y la confianza. Además permitimos que los impedimentos que estaban impidiendo completar una tarea salieran a la luz mucho antes (ahora lo harían en 24 horas o menos).

Desde 2005 desaliento fuertemente la estimación y medición de las tareas en horas en todos los equipos con los que trabajo. La regla de “tareas de un día” descubre el velo rápidamente sobre muchos impedimentos y disfunciones. Además libera a los desarrolladores de una irritante labor administrativa y les permite concentrarse en su verdadero trabajo. Las tareas por sí solas carecen de valor, ya que son siempre meros pasos intermedios. La historia o pedido es lo que resulta de interés para el cliente al fin y al cabo.

Hacer scrum requiere de un tremendo cambio en la forma en la que pensamos y nos comportamos. Liberarte de la noción de que medir en horas es útil o necesario va a significar un enorme avance hacia el horizonte ágil.

23 de junio de 2009

Anexo tendencioso: Es fácil decir que no

Cada vez que presento la idea de tener tareas de como mucho un día aparece en la audiencia al menos una persona que afirma tener tareas que “jamás” tendría sentido dividir en etapas equivalentes a una jornada laboral. El argumento para defender la indivisibilidad siempre navega entre la extrema complejidad y lo trabajoso de llevar a cabo la partición. Tras haber tenido este tipo de conversaciones a lo largo de los años, creo que soy capaz de leer entre líneas. Muchas veces la gente dice una cosa, pero su rostro transparenta otra, generalmente relacionada con algún temor o prejuicio.

Voy a generalizar en este caso, lo admito, pero me atrevo a afirmar que la gran mayoría de las veces quien no se atreve a dividir una tarea en subtareas de como mucho un día oculta un profundo y reprimido deseo de no-colaboración. Las tareas de varios días tienen consecuencias poco aparentes pero fatales para la cooperación entre los miembros del equipo. Quien se encuentra abocado a una tarea “larga” será como mucho un zombie durante la reunión diaria. Balbuceará algo así como “sigo haciendo XYZ, sin problemas” y pondrá los ojos en blanco, mientras sus compañeros relatan, escuchan y se entremezclan. Quien tiene una tarea “larga” no tiene tiempo de ayudar, porque está muy ocupado, por lo que poco tiene para escuchar. Durante el día hará bien en ponerse sus mejores auriculares: no solo tiene mucho para hacer, sino que su labor es tan compleja y enrevesada que nadie es capaz de ayudarlo en caso que lo necesite. Recién al final de los interminables días que se suponía tomaría la tarea puede percatarse de que, contra su propio pronóstico y lo que vino diciendo día a día, está retrasado. No me ayuden, puedo solo, nadie más lo entiende. El antónimo perfecto de scrum.

¿Test(osterona)?

Los hombres son de Desarrollo y las mujeres son de Testing. La intención no es hacer una afirmación políticamente incorrecta, sino solamente una observación. En todos estos años he trabajado con numerosas compañías de software y siempre, vaya a donde vaya, la proporción de mujeres por hombre es mucho mayor en pruebas que en desarrollo ¿Por qué será? ¿Qué les atrae del testing? O tal vez vale la pena preguntarse lo contrario: ¿hay algo en el desarrollo que les cause rechazo? Para variar, tengo mi teoría.

En los ambientes más tradicionales, el sector de desarrollo suele caracterizarse por la existencia de héroes, actitudes machistas por doquier y una competencia feroz. Este panorama no hace sino alimentarse glotonamente del deseo reinante de ascender cualquiera sea el costo, con tal de sentirse alguien, poder gozar a quien quedó atrás en la carrera y tal vez tener un cubículo con vista al parque. En ese paisaje lo que vale es el ego, la discusión acalorada y ganar, siempre ganar. La energía que se respira es, hay que decirlo, bastante masculina. No es común ver prosperar a una mujer en un lugar como ese. Lo más usual es que la mujer se aparte de la toma de decisiones, obedezca en vez de liderar y rechace gentilmente cuando se le quiera dar una gran responsabilidad. No digo que siempre suceda esto, pero sí a menudo. Algunas mujeres logran elevarse hasta puestos gerenciales en departamentos de desarrollo y vaya que tienen un estilo duro. Casi se puede sentir que perciben que deben ser aún más duras que sus pares masculinos para poder sobrevivir en este lugar. Las gerentes de desarrollo son a mi entender la excepción que confirma la regla.

Un segundo punto que quiero poner sobre la mesa es que el buen testing requiere mucho más humildad que el buen desarrollo. Los testers suelen ser más modestos que los desarrolladores; se podría decir que está en la naturaleza del rol. En cada uno de esos mundos hay diferentes energías en juego: el desarrollo se caracteriza por la energía de la creatividad, mientras que el testing lo hace por la del servicio. Las mujeres tradicionalmente gravitan hacia este último.

Si pensamos el software desde el punto de vista tradicional, el testing sigue al desarrollo. Es interesante que en las sociedades más tradicionales de rasgos paternalistas la mujer sigue al hombre ¿Dirá esto algo sobre nuestra culturas corporativas?

La misión de scrum es cambiar la manera en la que trabajamos. No estamos hablando de cambio de proceso, sino más bien de cambio de cultura. La gente que trabaja en un entorno ágil/scrum se comporta (esperamos) de un modo diferente. En el mundo ágil se habla habitualmente de tener desarrolladores “infectados por el testing” y eso está muy bien. Tenemos desarrolladores que no solo ven valor en el testing, sino que también lo practican, en vez de arrojarlo con desprecio y desinterés a la gente de QA hacia el final del proceso ¿Y dónde deja parado todo esto al tester? Como no podía ser de otra manera, voy a recurrir a tres mujeres para escuchar posibles respuestas. Abby Fichner planteó lo siguiente en un ensayo que publicó sobre testing ágil en 200912:

Los testers pueden perfectamente trabajar con los clientes de antemano, antes de que la funcionalidad misma sea desarrollada. Pueden llegar mucho más allá de lo que dice el requisito, para así poder entender qué se necesita para que la funcionalidad sea de hecho útil. O sea, el criterio por el cual la evaluarán los usuarios. Al fin y al cabo el éxito está definido por cuán útil es el software, no por la fidelidad a la documentación. Entonces, si los testers van a tener que encontrar la manera de validar que [el software] cumple con las necesidades del usuario, ¿por qué no tratar de dilucidar cuáles son esas necesidades de antemano, permitiendo que ese conocimiento ayude a direccionar al desarrollo por la buena senda? La verdad es que dejar su trabajo para el final, tratando de inyectar calidad en algo que ya está construido, no solo es un desperdicio de las capacidades de los testers, sino también un llamado a la frustración asegurada.

Lisa Crispin y Janet Gregory han escrito y mucho sobre el rol del tester en un equipo ágil13. Han definido el rol de esta manera:

...un tester profesional que le da la bienvenida al cambio, colabora de forma productiva tanto con la gente técnica como del negocio y entiende el concepto de utilizar pruebas para documentar requisitos y orientar el desarrollo. Los testers ágiles tienden a desarrollar buenas habilidades técnicas, saben colaborar con otros para automatizar pruebas y son experimentados testers exploratorios. También están dispuestos a aprender lo que los clientes hacen de forma tal que puedan entender mejor los requisitos de software del cliente.

Nada más lejano del típico tester que aparece hacia el final del proceso y rige su conducta obcecadamente respecto del plan. Esos que a lo sumo sirven como cancerberos al acecho de desarrolladores chapuceros.

No tardamos como comunidad en darle la bienvenida al concepto de “desarrolladores infectados por el testing”, ¿pero qué pasa con su contraparte del mundo del testing? “Testers infectados por el desarrollo” suena como la alternativa más obvia, pero es francamente inadecuada. De lo que hablamos no es de escribir código, así que mejor la descartamos. Creo que prefiero el concepto que surge del término “Testers infectados por la creatividad”. Quiero encontrarme con testers apasionados por la creación de software y no solamente por la validación de un software que hizo algún otro. Quiero ver testers que formen parte integral del proceso creativo, desde los requisitos hasta la entrega. Quiero individuos que tejan y se permitan formar parte del tejido. Es hora de escuchar e incorporar a esa voz tímida, siempre guiada por la intuición. Tenemos que salirnos de ese patrón tan arraigado que nos habla de testers que funcionan como un mero apoyo de los desarrolladores. Mujeres que apoyan a sus hombres. Necesitamos pelear por la igualdad en nuestras relaciones en el software, así como peleamos por la igualdad en nuestros matrimonios.

Las mujeres necesitan reivindicar el lugar que les corresponde en el proceso creativo. Los ambientes ágiles, así como los ambientalistas ágiles, crearán el espacio para que esto ocurra, pero en definitiva depende de cada individuo moverse hacia ese espacio, tanto desarrolladores infectados por el testing, testers infectados por la creatividad o simplemente hermosos artesanos. Es la hora. Actuemos.

25 de Junio junio de 2009

Anexo tendencioso: En scrum todos hacen todo, o la falacia del pacato laboral

“Scrum no nos sirve, porque en scrum todos hacen todo y eso en nuestro caso es imposible”. Si habré escuchado esa frase por parte de especialistas que dolorosamente intentaban resistirse a una movida hacia la agilidad. Es tan fácil criticar una idea llevándola al extremo con tal de no movernos de nuestra comodísima inercia. Scrum no afirma en momento alguno que cada uno de los miembros de un equipo debe ser capaz de realizar cualquier tarea con la misma calidad y eficiencia. Lo único que pedimos en scrum es simplificar los objetivos: que nadie por fuera del sistema le diga a sus partes qué tienen que hacer, sino que simplemente le pida al sistema completo que haga lo que pueda para poder cumplirlo. La autoorganización solamente emerge cuando existe heterogeneidad entre sus partes integrantes, por lo que no solo no queremos eliminar la diversidad, sino que de hecho la necesitamos.

Si se fijan con cuidado, suelen ser los especialistas más especializados aquellos que recurren a este argumento para criticar la adopción del framework. Ésta suele ser una posición entendiblemente defensiva que no ayuda a nadie. La especialización redunda en muchas ocasiones en equipos inflexibles, incapaces de adaptarse a cambios en la carga de trabajo, e incluso poco colaborativos, ya que difícilmente podremos cooperar en un asunto del cual desconozco hasta el detalle más básico. La salida, como siempre, es usar el ideal como mera inspiración y tener objetivos a corto plazo que nos hagan dejar el lodo enmohecido en el que estamos atascados sin siquiera saberlo. Pensar en que no haya especialidad sin al menos un suplente, que todos sean suplentes de al menos una especialidad y que, por último, nadie le haga asco a nada, suele funcionar como meta difícil, aunque alcanzable. Una vez que lleguemos, no antes, secaremos la transpiración de nuestro rostro y escudriñaremos el horizonte, buscando una nueva colina que escalar.

Pagando la deuda técnica

...el movimiento ágil se ha enfocado en lograr altos niveles de involucramiento del cliente, lo cual es bueno per se, pero hemos ido demasiado lejos. Muchos agilistas denuncian que no pueden lograr que las organizaciones se enfoquen en prácticas técnicas ¿Por qué debería ser una sorpresa si alentamos en la práctica que los gerentes/dueños de producto tomen todas las decisiones de priorización y luego midan el rendimiento utilizando velocidad?”

Este fragmento de una nota de Jim Highsmith evocó en mí una experiencia que tuve hace ya varios años mientras trabajaba como scrum master/coach de un equipo en la ciudad de Nueva York. Quisiera contarles cómo manejaba este grupo tanto su excelencia como su deuda técnica:

Cuando un miembro del equipo se topaba con código mal escrito, irrelevante o simplemente desprolijo (incluyendo código al que le faltaban pruebas unitarias) durante una iteración, no lo arreglaba en el momento, salvo que escribir ese código haya sido fundamental para desarrollar la funcionalidad en la que estaba trabajando en ese momento. En cambio lo que hacía era tomar nota del archivo, número de línea y funcionalidad correspondientes en uno o más Post-Its, que luego ubicaba en una sección aparte del tablero intitulada “Deuda Técnica”. Luego simplemente continuaba trabajando en aquello que había sido comprometido para el sprint.

Durante la reunión de planificación del sprint, cuando alguien requería una funcionalidad, al menos un miembro del equipo (generalmente más de uno, ya que todos repasaban activamente estas notas) sabía si había áreas riesgosas en el código asociado. Esto se mencionaría, discutiría y, obviamente, se tomaría en cuenta a la hora de estimar el esfuerzo. El equipo tenía una política, comunicada y acordada con el negocio, de nunca agregar deuda. Ignorar los problemas existentes termina agregando deuda, lo que a su vez incrementa el interés y conduce finalmente a una catastrófica bancarrota técnica.

Si el product owner quería de todos modos esa funcionalidad, el equipo simplemente tomaba los Post-Its que describían esa deuda técnica y los ubicaría como tareas asociadas a esta historia, lo que permitiría arreglar el código asociado antes de o durante la creación de la funcionalidad. De más está decir que las nuevas funcionalidades se desarrollaban siguiendo los estándares de excelencia que el equipo había definido para sí mismo.

Este simple proceso lograba que la calidad de código fuera un tema visible para todos. Aun sin tener un entendimiento técnico de la cuestión, cualquiera podía entender lo que estaba sucediendo con respecto a este tema contando la cantidad de notas y pidiendo, siempre entendiendo las consecuencias, que el número baje lo antes posible. También permitía a los desarrolladores tener alguna evidencia a la que referirse cuando generaban una estimación más alta de lo que se esperaba. En retrospectiva tal vez su función más importante haya sido la de crear un espacio de diálogo abierto y enfocado al valor entre los desarrolladores y el negocio.

He utilizado esta técnica en varios equipos desde entonces, pero no la he visto en práctica en otros lados. No es fácil, pero creo que es esencial tener un mecanismo como éste para lograr un diálogo saludable y superar los escollos que menciona Jim Highsmith en su artículo. El problema no es ni usar la velocidad como medida, que puede ser útil si se la aplica de forma apropiada, ni dejar la priorización en manos del negocio (es su función al fin y al cabo). El problema, como siempre, es la ausencia de un diálogo franco y colaborativo, sin el cual habrá individuos mal informados, que asumirán sin conocer, sacarán conclusiones erróneas y tendrán enormes pero falsas expectativas.

12 de febrero de 2012

Anexo tendencioso: Si no tuviera valor, no lo haríamos

Muchos desarrolladores me preguntan a menudo cómo hacer para incluir lo que denominan “tareas técnicas” en el backlog del sprint siendo que, según sus palabras, esa tareas no agregan valor al negocio. Mi visión es taxativa y tiene dos partes. La primera es que si no agrega valor, no lo hagamos. La segunda es que todo refactoring trae valor al negocio, al mediano plazo y en forma de menor costo de cambio. Aprendemos en la universidad que el costo del cambio crece exponencialmente al avanzar un proyecto de desarrollo. Dinámica tolerable si vemos al mundo como proyectos que empiezan y terminan, pero en scrum la vida transcurre más bien en términos de productos que viven por años y años. Por algo no tenemos “project owners”, sino más bien product owners. El costo del cambio podrá crecer, como mucho, linealmente. Para ello debemos evitar que nuestro software se pudra, repleto de hongos y musgo. La única manera conocida de prevenir semejante decaimiento se llama refactoring y tiene un valor tangible, pero a futuro.

El refactoring no es posible sin tener pruebas automatizadas que nos respalden. Los tests automatizados son meramente testimoniales si carecemos de un buen sistema de integración (o mejor aún, de delivery) continua. Pensar que las prácticas técnicas no entregan valor al negocio implica no solamente una miopía de notables proporciones, sino que denota una sutil soberbia por parte de los miembros del equipo. A lo largo de nuestra vida profesional los desarrolladores logramos comprender y modelar la esencia del quehacer de abogados, ingenieros, médicos, comerciantes, cajeros y gerentes. Definimos entidades, reglas y hasta nos animamos a proponer cambios y mejoras al propio negocio. Y sin embargo pensamos que nuestra ciencia es tan oculta, tan inabarcable por meros mortales, que ninguno de nuestros clientes, sean abogados, médicos o gerentes, podrán comprender jamás la esencia de eso que llamamos arquitectura, jerarquía de clases, capa de negocios y legibilidad de código. Si no somos capaces de esforzarnos en abstraer y resumir lo más básico de nuestra disciplina, cualquier probabilidad de trabajo colaborativo con el cliente quedará sepultada en una opaca capa de soberbia, incomprensión, prejuicio y resentimiento. Hablemos, vale la pena.

El explorador ágil

Mientras realizaba una consultoría en Indianápolis mantuve una conversación con un desarrollador que recuerdo comenzó con la frase “¿Qué sabes sobre energía nuclear?” El tipo me contó que había trabajado en una central nuclear, donde se entrenaba continuamente a todos los empleados en los procedimientos de seguridad, aún si éstos eran veteranos con años allí. Me decía con gran seguridad que mantener a la gente al día con las últimas prácticas y con recordatorios permanentes sobre las buenas prácticas ayudaba a prevenir un accidente nuclear. Luego me preguntó, con gran tino, por qué la educación ágil se daba solamente al comienzo de un proceso de cambio, sin refuerzos posteriores. Me comentó que había visto la misma historia repetirse en varias compañías que comenzaron a hacerlo bien luego de la capacitación, llenos de entusiasmo y aprendizaje, pero cuya energía decayó estrepitosamente mientras todo el mundo caía en los cómodos brazos del antiguo paradigma. “Las empresas de software también tienen sus Chernobyl”, resumió.

Esta charla me llevó a reflexionar sobre las formas en las que las compañías deciden introducir y aplicar scrum. Su enfoque se basa en contratar por un período muy corto un consultor o capacitador. Las empresas más comprometidas con el cambio contratan scrum masters, usualmente solicitando que el candidato haya sido certificado por alguna de las cada vez más numerosas entidades que entregan estos títulos, como si esto brindara algún tipo de garantía sobre sus habilidades. Ambas estrategias son en exceso superficiales.

A menudo observo con preocupación que el propio término “scrum master” se ha convertido en un lastre para el movimiento ágil, así como el rol representa un obstáculo para lograr una verdadera autoorganización. Si bien la intención original es noble, el rol en la práctica se convierte, en más de una organización, en un simple recolector de métricas y un molesto policía del proceso o hasta, desastre en puerta, un “gerente de proyecto ágil”. Cuando esto ocurre se termina arrebatando la responsabilidad del equipo, que deja de estar genuinamente comprometido para pasar a estar subordinado a un proceso que se percibe como impuesto por la fuerza y bajo estricto control.

Durante los últimos dos años me di cuenta que cada vez hablo menos del rol del scrum master cuando enseño scrum. Prefiero ubicar scrum como una relación entre product owner y equipo, para luego explorar esa relación en término de cultura de equipo, foco, alineamiento y colaboración. Ésa es la promesa de scrum al fin y al cabo: equipos comprometidos y clientes satisfechos. Pero es cierto que este enfoque no previene los Chernobyl, ya que no impulsa a la organización a adoptar un modelo sostenible de mejora continua inspirado en los principios fundacionales de scrum y el framework que los sostiene.

Contratar scrum masters no es la solución. Siempre terminan ubicándose muy debajo en el jerárquico tótem corporativo y suelen reportar directamente a un gerente de desarrollo o director de la oficina de gestión de proyectos. Tienen poca autonomía y caen fácilmente en una posición de complicidad con el statu quo.

Tampoco creo que el coaching ágil sea la solución. El coaching puede ayudar a los individuos y a los equipos a los que pertenecen a progresar y superarse. Pero así como en la terapia llega un momento en el que el paciente debe caminar por si solo o arriesgarse a caminar en infinitos círculos junto al terapeuta al tiempo que construye una relación poco saludable de interdependencia, el coach debe dejar ir a su cliente para que su trabajo termine siendo efectivo. Lo que realmente necesitamos es inyectar agilidad en el ADN de la organización. Sabemos que podemos cambiarlo introduciendo un virus que sea lo suficientemente potente como para confrontar y vencer a los anticuerpos con los que lo desafiará la corporación. Si vamos a cambiar la organización, necesitamos plantar ese virus.

Quisiera entonces proponer un nuevo rol, un agente viral: El explorador ágil. Vale aclarar que esto no se parece ni un poco al clásico “campeón o sponsor ágil”, quien suele ser un CEO o gerente de desarrollo que alegre y caprichosamente un día proclama “¡Seamos ágiles!”, pero que no necesariamente entiende el grado de transformación organizacional que se requiere o que, incluso, no tiene ni el tiempo ni el compromiso necesario para que se produzca ese cambio.

El explorador ágil, nuestro agente de cambio, es alguien que persigue el conocimiento y se aventura en terreno desconocido. Es un(a) soñador(a) intrépido(a) que inspira a otros a través de sus acciones más que a través de sus palabras. El explorador ágil es un puesto de tiempo completo e idealmente no debería depender de nadie, pero si es imprescindible que lo haga, entonces que reporte al CEO, pero desde un rol autónomo, que no será medido de acuerdo a su desempeño. Esta persona no tiene como objetivo ser el coach de los equipos o ayudar a otros a hacer mejor scrum, sino que deambulará por ahí con el objetivo de escuchar, pensar, inspirar, confrontar, agitar, desafiar y abrir los ojos de la organización para que pueda ver nuevas posibilidades, sembrando la semilla de nuevos modos de ser y hacer.

Un buen explorador ágil deberá ser un miembro activo y comprometido con la comunidad ágil que exista más allá de la empresa, participando de eventos y discusiones en foros, leyendo todo el material que caiga en sus manos, creando diálogos con otras organizaciones e individuos, organizando charlas y talleres en la compañía, generando ideas que fomenten la experimentación que permita la mejora permanente y, tal vez su tarea clave, inspirando a que otros hagan lo mismo.

El explorador ágil tomará silos y jerarquías corporativas y las entretejerá formando una obra de arte cinética, creando una sensación de estupor y fascinación entre los espectactores14. En semejante hábitat la autoorganización prosperará, el coaching de a pares emergerá como una alternativa a la mano de obra de alquiler, tan costosa y difícil de motivar, el compromiso se profundizará y el placer aparecerá en escena, alejando la perspectiva de un desastre nuclear, un lunes feliz a la vez.

19 de abril de 2012

Anexo tendencioso: Necesario, ridículo e inexplicable

El scrum master es un rol raro, particular, difícil de transmitir y digerir. Su nombre es absurdo, paradójico desde su formulación misma ¿Cómo y por qué tendría que haber un “master” de “scrum”? ¿No contradiría la propia esencia del framework? Lo que tal vez haya comenzado como un mal chiste de Ken Schwaber se ha convertido en un lastre, que embrolla todo intento de explicar qué debe hacer este actor que tan poco encaja con las estructuras mentales y organizacionales que pueblan el paisaje corporativo de hoy en día.

El scrum master, junto a su gran herramienta, la retrospectiva, tienen tal vez una única y valiosísima misión: poner sobre la mesa aquello sobre lo que no se habla. El proceso, la manera de hacer las cosas, nuestro “arte”, la forma de trabajar, será ahora tema de charla, objeto de estudio, ciudadano de primera clase. Las personas, los equipos y las organizaciones suelen vivir una realidad dolorosa pero anestesiada por la inercia y la resignación. Los lunes apestan, el trabajo es un infierno necesario, la vida comienza el viernes por la tarde. El scrum master vino al mundo para quitarnos esa anestesia, para que vuelva a doler lo que siempre debió molestar, pero que hoy forma parte del paisaje cotidiano. El scrum master es un abejorro en la pared, hace nada con elegancia, parafraseando al gran Harrison Owen. Si hace bien su trabajo, nadie sabe que está ahí. Pero como dijo Libertad a Mafalda, un abejorro no puede detener un tren, pero puede llenar de ronchas al maquinista. El scrum master, el abejorro justiciero, interviene cuando la realidad conspira contra sí misma. El scrum master molesta preguntando lo obvio, moviendo estructuras, criticando firme y delicadamente, insistiendo hasta el cansancio, humanizando la corporación una charla sincera a la vez. Y como siempre, la unión hace la fuerza. No dejen solos a sus scrum masters. Háganlos formar parte de un equipo kaizen, cuyo product owner sea aquel gerente que mejor comprende la esencia ágil. Tengamos un verdadero panal del cambio, polinicemos y, sobre todo, que el maquinista no deje de rascarse.

La emotividad sincera es el nuevo hardcore15

Mi enfoque para enseñar agilidad suele ser descrito como un tanto sensiblero16. Este término suele utilizarse como un insulto y, si bien podría tomarlo con pinzas y algo de distancia, el miedo y la ignorancia que pueden descubrirse tras esta palabra me ponen francamente triste. Tengo la sensación de que demasiada gente dispara esa palabra para describir modos de interrelación personal que no logran comprender, lo que suele ser una realidad cotidiana en el mundo del software. No es más que una forma defensiva de restarle importancia a una forma de interacción que resulta difícil para muchos informáticos y profesionales de disciplinas aledañas. Desestimar esas interacciones como sensibleras o “soft” es una manera sencilla de evitarlas por completo. En pocas palabras, están esquivando el bulto.

Nuestro sector alberga la percepción de que dar órdenes, fijar fechas, estar detrás de cada movimiento, amenazar con la degradación y el despido y mostrarse implacable en general es un enfoque “hardcore“ del management, mientras que escuchar, promover un diálogo saludable, promover la autoorganización y resolver conflictos es considerado “soft” ¡Es justamente al revés!

La gestión del tipo comando-y-control17 está directamente basada en el miedo y no significa más que vociferar sin un coraje que respalde los gritos con acciones. No hay nada “hard” en algo así; de hecho su ineficacia termina demostrando que quien utiliza este enfoca termina mostrándose tristemente impotente.

Mi colega Matt Smith, actor y docente de improvisación, dice lo siguiente sobre los ejercicios de improvisación: “No hay nada blando aquí; esto es verdaderamente duro, esto requiere coraje en serio”. Lograr trabajar con otra gente es enormemente desafiante y difícil. Esto no es sensiblería, sino emotividad sincera. Mucho más “hard” que “soft”.

La visión del mundo que propone scrum nos obliga a desafiar cada una de las verdades que consideramos inmutables con respecto al modo en el que hacemos nuestro trabajo. Si alguna vez te descubres utilizando el término “sensiblero” cuando las cosas se ponen incómodas, o describiendo las relaciones humanas como algo “soft”, por favor frena por un momento y reflexiona sobre los motivos que están detrás ¿No te estarás escondiendo de algo? ¿Estás avergonzado? ¿Con miedo? Sé honesto contigo. Trata de reformular la frase e intenta comenzar a apreciar cómo suele haber cariño, amabilidad y hasta amor en las relaciones personales que recorren como ríos subterráneos cualquier experiencia exitosa de trabajo en equipo y por ende todo proceso de desarrollo creativo de producto. Procura reconocer que construir esas relaciones requiere de un enorme coraje.

Es hora de sincerar cada gota de emotividad que ocultamos detrás de tanta máscara ¡Una tarea solo apta para gente dura!

14 de junio de 2009

Anexo tendencioso: No te escapes

El informático tiene una gran capacidad para escapar por medio de la crítica intelectual de aquello que lo incomoda. No caigas en tu propia trampa represiva, no censures automáticamente todo aquello que te acerca a tus emociones y a las de tus compañeros. A la celestial tríada del valor agregado, la calidad y la satisfacción se llega por la tortuosa vía de la introspección y la transparencia radical. Sí, incluso la emocional.

Un scrum popular

Durante todos estos años en los que he estado enseñando y promoviendo scrum he rechazado de plano la idea de que esta es una metodología o un proceso. Muy por el contrario, he procurado difundir la noción de scrum como framework que permite que emerjan disfunciones organizacionales y que impulse a los individuos hacia una nueva manera de pensar el trabajo. En definitiva, scrum como una fuerza de cambio. Recientemente, y en coincidencia con el crecimiento de kanban, he comenzado a escuchar a cada vez más gente referirse a ambos conceptos como meras herramientas18. Esto, se lo pueden imaginar, no hace más que preocuparme.

No tengo nada en particular contra las herramientas. Cuando facilito talleres o trabajo como consultor dentro de organizaciones, suelo introducir el concepto de estimación relativa. Como parte de esta explicación presento generalmente Planning PokerTM, un juego de cartas definido por James Grenning y popularizado por Mike Cohn, que permite estimar en equipo minimizando la influencia de los pares. Planning PokerTM es básicamente una herramienta. El template “Como X/Quiero Y/Para que Z” que muchos hemos utilizado alguna vez para redactar historias de usuario, inventado por un equipo de la empresa Connextra y popularizado por Cohn, es también una herramienta19. De hecho, utilizar un objeto para marcar quién tiene derecho a hablar durante una reunión, trazar una línea de tiempo cuando hacemos una retrospectiva y tantas otras técnicas que empleamos para llevar a cabo de forma efectiva nuestro trabajo bien pueden ser consideradas herramientas. Pero scrum en sí no es ni nunca deberá ser una simple herramienta. Scrum es una manera de pensar la forma en la que trabajamos, es una manera de ser, un viaje, una aventura, una exploración de uno mismo y del entorno que nos rodea. Reducirlo a “una herramienta” significaría desperdiciar toda su magia y arrojarnos violentamente y sin aviso al oscuro y siempre tan obtuso mundo de las mejores prácticas y los procesos repetibles. Caer en semejante facilismo nos ahorraría el dolor propio de la transición, pero también limitaría el alcance que podría tener la mejora. De ese modo jamás lograremos mejoras sustanciales en el valor que entregamos a nuestros clientes, la calidad que tienen nuestros productos o el bienestar que podemos llegar a experimentar al llegar a la oficina cada mañana.

Me apena sobremanera escuchar a tanto agilista referirse a scrum como “una herramienta más en mi maletín”, prácticamente intercambiable con kanban y hasta con XP. Tal vez kanban sí sea una herramienta, que puede ser utilizada para hacer que un proceso gane en eficiencia, básicamente midiendo y mejorando el flujo de valor. David Anderson, su principal impulsor en el mundo ágil, lo describe como un proceso, pero yo lo veo de ambas formas. XP, como scrum, puede potencialmente fomentar el cambio sincero, sentido, ya que ofrece una serie de valores que podemos incorporar a nuestro trabajo diario. Sin embargo, debido al fuerte foco que hace en la programación, se lo suele considerar un mero conjunto de prácticas y herramientas de desarrollo (programación de a pares, test-driven development, integración continua, etc.), por lo que rara vez se lo utiliza del modo holístico en el que fue ideado originalmente. Tal vez lo que suceda es que, como ocurre con scrum, utilizar verdaderamente XP va más allá de la zona de confort del desarrollador promedio.

La otra dirección en la que veo que se dirige scrum es la que podríamos describir como “mejor práctica”. Me pone realmente incómodo cuando veo a Jeff Sutherland intentando alinear scrum con CMMi20. No es que me oponga (aún), pero sí me preocupo. Mi sensación es que todo esto representa un paso en el camino hacia la híperproductividad, la riqueza instantánea, la ultraeficiencia y, por ende, muchos pasos en la dirección contraria al simple placer de trabajar. Creo fuertemente que es más probable, sano y sustentable entregar valor de negocio y aumentar ganancias desde una mirada de amor y satisfacción por aquello que hacemos, desde un sentido de cuidado y pasión, que a partir de un algo cuyo nombre técnico empieza con el prefijo híper- o ultra-. Quiero pelear por un Scrum Popular, no por un Scrum Gerencial y menos aún por un Scrum del Inversor o del Consultor. Creo que un Scrum Popular es el único sostenible y verdadero.

El Scrum Popular es un scrum creado por la gente para la gente, que es distinto del scrum que baja del monte escrito sobre rígidas y celestiales tablas, o su equivalente en forma de libros, cursos y consultoría. El Scrum Popular crece orgánicamente a través de la educación, la práctica, el error y la reflexión. Abro las puertas de mi corazón a los mensajes contradictorios que envían los distintos practicantes de scrum, a todas las polémicas, discusiones y desacuerdos que pueblan listas de correo y blogs. El trabajo del conocimiento nos plantea un terreno minado, complejo, indescifrable, que sólo podrán recorrer con éxito aquellos equipos que trabajen genuinamente de modo colaborativo. Es lógico entonces pretender que entre todos, ayudándonos unos a otros, encontremos el camino. Va a ser una caminata larga, tal vez interminable, pero al menos la hacemos nosotros. Es nuestra aventura, no la de ellos.

Scrum es un framework que promueve el cambio organizacional y la liberación personal. No es una metodología ni un proceso y se podría decir que es muchísimo más que una herramienta. Scrum nos desafía a pensar el mundo de un modo radicalmente nuevo y diferente. Debemos aprender a dejar de trazar paralelos con nuestros modos actuales y comenzar a pintar usando colores inusuales y patrones ilógicos en hojas en blanco. Recién ahí, recién después de haber tomado la decisión consciente de pintar un nuevo cuadro en un nuevo lienzo, vamos a empezar a entender de qué se trata esta cosa llamada scrum.

6 de diciembre de 2009

Anexo tendencioso: ¿Tiene sentido hablar de un scrum popular?

Scrum es sin duda el más comercial de los frameworks ágiles. Ninguna otra variante de la agilidad ha movido tantos dólares entre textos, aplicaciones, certificaciones, conferencias, consultoría y educación ¿Cómo se puede pretender que una disciplina con un prontuario tan suntuosamente mercantilista sea considerada popular?

A simple vista la propuesta parece una broma de mal gusto. Sin embargo, la gesta que propone Tobias no parte de la complicidad y la hipocresía, sino justamente del desarme de semejante nudo gordiano. El desafío está en desandar la paradoja misma, tomando la esencia de aquello que se propone en scrum, quitándole todos sus ropajes corporativos y transformándolo en la más espartana, radical, sincera y poderosa de las variantes.

La pregunta que quiero hacerme delante de ustedes es para qué sirve conservar el nombre tras tanto malentendido y perversión ¿Será confianza o simple especulación publicitaria? ¿Vale la pena reinventar o será mejor recuperar la esencia de lo que supo ser bueno y ahora parece ahogarse en su propia estela? Creo que la clave está en entender que hay más para conservar que para eliminar de aquello que constituye hoy en día scrum en el mundo real. El gran cambio, entiendo yo, radicaría en modificar el origen del impulso de scrum en tanto movimiento. No es tanto lo que ganaríamos cerrando instituciones certificadoras, sino más bien lo que lograríamos si más gente se decidiese a utilizar scrum como un verdadero motor transformador de vidas y organizaciones.

El Scrum Popular será aquel que no se detiene ante el instinto conservador del statu quo, emancipando a todos y cada uno de los miembros de una organización, sin importar rango e historial. Scrum Popular será aquel que cambiará cuando tenga que cambiar. Scrum Popular será aquel que fomente los cambios más profundos en la vida corporativa, incluyendo el reparto del dinero y el poder. Scrum Popular será impopular o no será.

Proceso:
El Sendero Escarpado

El proceso es simplemente “la forma en la que trabajamos” y por ende un proceso ágil será siempre emergente, nunca prescriptivo. En la agilidad hablamos de un concepto llamado release: dejar el control férreo de lado, sencillamente porque confiamos. El proceso que construiremos surgirá luego de quitarnos de encima todo aquello que carece de sentido, lo que representa un desperdicio, creando el espacio necesario para que la gente piense por ella misma, creando nuevos ritmos, nuevas maneras de colaborar, confrontar y explorar, antes que limitarse a obedecer y ejecutar. Un principio clave de cualquier método ágil es el aprendizaje, usualmente descrito a través del concepto de la inspección y adaptación. Si no comenzamos haciendo, construyendo, por más torpemente que lo hagamos hoy en día, nada tendremos para inspeccionar. Por ende todo proceso ágil requerirá acción y, en consecuencia, error.

Scrum: Un lugar en el mundo

Scrum no nace de un repollo. No constituye un hecho aislado, una eventual anomalía del mundo del desarrollo de software, sino que emerge de un algo que lo trasciende. La iniciativa ágil en su conjunto no es más que una diminuta parte de un movimiento mucho mayor que viene tomando fuerza lenta pero sostenidamente en el mundo de las organizaciones. Estamos viviendo el comienzo de un salto de paradigma digno de Kuhn21, que nos llevará desde un modo de razonar mecanicista hacia uno que nos permita ver el mundo desde una perspectiva más humana, más orgánica. La teoría que subyace detrás de esta nueva mirada del mundo se conoce como complejidad, en particular el estudio de los llamados sistemas adaptativos complejos22. Un libro que describe de manera profunda e inteligente este cambio en la forma de pensar y comportarse focalizándose en el mundo de los negocios es Surfing the Edge of Chaos (“Surfeando el Borde del Caos”), de Richard Pascale, Mark Milleman y Linda Gioja23. Es tal vez uno de los primeros libros que recomiendo a gerentes y agentes de cambio con los que me toca trabajar. En él podemos encontrar básicamente consejos para que los líderes conviertan a sus empresas en “’sistemas vivos’ ágiles y adaptables, que alcanzan una vitalidad que perdura en el largo plazo de manera sostenible, en un medio que evoluciona drásticamente”. El libro está sazonado con ejemplos reales de enormes compañías (como Shell o Sears) que decidieron emplear enfoques y conductas complejas y adaptativas, logrando tanto pingües ganancias para sus accionistas como genuina satisfacción entre sus empleados.

El Plexus Institute24, una organización dedicada exclusivamente a promover esta clase de ideas, nos entrega la mejor explicación que haya leído hasta el momento sobre qué es realmente un sistema adaptativo complejo y cuál su relevancia:

¿Qué es la ciencia de la complejidad? En resumidas palabras, se podría decir que es el más reciente intento que ha hecho la ciencia de explicar cómo emergen el orden y la innovación (y como tal podemos considerarlo el sucesor intelectual de la teoría de sistemas y la teoría del caos). La perspectiva tradicional, en cambio, presenta una visión mecanicista del mundo natural, que se encontraría compuesto de entidades que pueden ser comprendidas con solo extraerlas y examinar sus componentes.

La humanidad ha aprendido muchísimo sobre la naturaleza utilizando este último enfoque, pero la vasta mayoría del mundo al que nos enfrentamos no encaja con ese modo de entender las cosas. Esto se debe sobre todo a que la mayor parte de la naturaleza está formada por lo que en las ciencias de la complejidad se denominan sistemas adaptativos complejos no lineales. Estos sistemas están compuestos por un número de agentes diversos e independientes que están constantemente cambiando e interactuando entre sí. Cuando se trata de sistemas adaptativos complejos, estudiar solamente las partes siempre genera un entendimiento incompleto del todo. Algunos ejemplos de esta clase de sistemas podrían ser las colonias de hormigas, los ecosistemas y las organizaciones humanas.

Vale la pena hacer en este punto una distinción entre lo complejo y lo complicado. Un motor de combustión es complicado, dada la enorme cantidad de componentes diferentes que lo componen. Sin embargo no es complejo, porque conocer sus partes y cómo funcionan permite entender qué hace el sistema como un todo.

Los textos que ofrece la fundación de forma gratuita llegan al punto de afirmar que “esta forma de ver las cosas nos da nuevas y poderosas formas de pensar y actuar sobre cuestiones tan dispares como la ecología, la educación en la niñez y el liderazgo a niveles ejecutivos.”

Si tomamos en cuenta lo progresistas que resultan estas ideas, podemos suponer que los teóricos del Instituto Plexus son conscientes de la existencia del movimiento ágil. De hecho su marco de referencia parece lo suficientemente amplio como para haberlo contemplado, pero como buenos científicos sistémicos, se enfocan en los sistemas en general y no en un elemento tan diminuto de la realidad como lo son las organizaciones con fines de lucro. La descripción que hacen de lo que llaman “la característica distintiva de los sistemas adaptativos” se encuentra en consonancia con la mirada que debería tener un agilista que haga honor a su nombre:

...el orden que emerge a partir de las interacciones de los componentes de los sistemas complejos es “mayor –y diferente- que la suma de las partes”, para recurrir a una frase que nos es familiar. Por ende podemos afirmar que los sistemas complejos tienen un alto grado de imprevisibilidad. Lo que es aún más, el orden que emerge de forma colectiva a su vez influencia el comportamiento y las interacciones de las partes. Existen circuitos de retroalimentación en todos los niveles. Esta clase de sistemas se encuentran en un proceso de adaptación y evolución permanente...el orden del sistema como un todo fluye como consecuencia del control distribuido, o sea de las interacciones entre los individuos, y no a partir de un control central. Una forma de visualizar este fenómeno en las organizaciones, llamado autoorganización, es recordando qué ocurre en tiempos de crisis. En estos casos la gente toma las tareas que considera más necesarias, generalmente rompiendo con las normas o lo establecido, haciendo las cosas de una manera inusual. Se realizan proezas, que como si esto fuera poco suelen figurar entre las experiencias más gratificantes de toda vida laboral. A los líderes suele resultarles difícil ceder aunque sea una parte del control, ya que lo consideran parte de su propia identidad. Pero aquellos que lo logran ven cómo su gente da rienda suelta a sus talentos más ocultos, logrando mucho más de lo que ellos, o cualquier otro, jamás habría imaginado. He aquí el poder de mantener una mirada de las organizaciones basada en la complejidad.

Esta filosofía no implica que los líderes simplemente pueden relajarse, ceder por completo el control y sentarse a esperar que ocurran milagros impredecibles. Muy por el contrario, se propone enfáticamente que los líderes ayuden creando las condiciones que logren desencadenar entre su gente todo el talento latente que se encuentra desaprovechado. Es básicamente un modelo que promueve una figura de líder cultivador, lejana a la idea tan habitual del jefe controlador, paternalista, omnisciente y todopoderoso.

Mi intención aquí, pidiendo unas cuantas frases prestadas, es mostrarles que la agilidad promueve una manera de pensar y actuar hacia la que se debería evolucionar de manera natural. La respalda una sólida base teórica y científica, que la ubica a la vanguardia del pensamiento sistémico actual. Por ende, la agilidad debería ser tomada muy en serio por cualquier empresa de software que desee mantenerse en el mercado y competir en un mundo que cambia cada vez a mayor velocidad. Los mecanismos se hacen obsoletos al poco tiempo de nacer, por ello lo que necesitamos son formas de entender, aprender y crear. Las organizaciones que sobreviven a base de severidad, jerarquía y órdenes no son más que torpes dinosaurios que deambulan por el mercado con paso cansado, logrando que la innovación no haga más que languidecer. Para progresar, para florecer, para superarnos necesitamos un enfoque de management más laxo, alejado de tanto intervencionismo. Necesitamos rendirnos ante la fuerza del caos, utilizando a nuestro favor la potencia arrasadora del cambio. Debemos abrazar con nuestros corazones la creatividad innata de la mente humana, confiando, permitiendo que la gente navegue el espacio de posibles soluciones con mayor libertad. Necesitamos por ende crear sistemas y fomentar contextos donde la gente pueda brillar.

Esta nueva mirada requiere sin duda una ruptura con nuestros paradigmas existentes a nivel personal. No podemos hacer encajar esta nueva forma de trabajar en nuestro antiguo modo de ver el mundo sin que nada se rompa, se resquebraje, se parta en mil pedazos. Considerando que ya recurrí tantas veces en este ensayo a las palabras que comparte con tanta sabiduría el Instituto Plexus, creo natural cederles también las palabras finales:

Vale mencionar una última propiedad de los sistemas adaptativos complejos que es relevante para las organizaciones: cuando se mejoran las interacciones entre los agentes, mejora a su vez la adaptabilidad y creatividad del sistema.

En organizaciones humanas, los agentes vendrían a ser personas y las interacciones serían las relaciones que se generan a partir de conversaciones. Mejorar la habilidad de la gente para interactuar y construir relaciones mejora la adaptabilidad de la propia organización. Los científicos que estudian la complejidad han observado también que una diversidad de agentes en el sistema mejora esta adaptabilidad y creatividad aún más. En las organizaciones, esto implica que debemos promover una diversidad de experiencias y perspectivas”25.

26 de septiembre de 2008

Anexo tendencioso: Humildad, divino tesoro

La complejidad es tal vez el punto de partida, la razón, la motivación, la justificación para utilizar scrum. Pero no nos olvidemos de dar un pequeño paso hacia atrás, para reflexionar cuál es la precondición para comenzar a siquiera elucubrar cómo lidiar con la complejidad. No hay scrum si antes no vemos el trabajo que tenemos por delante como enormemente complejo. Considero que nunca podremos ver lo que tenemos delante de nuestros ojos como complejo sin una buena dosis de humildad intelectual. Nuestra educación y los traicioneros éxitos suelen conspirar para construir, en la mayoría de nosotros, una mirada del mundo intelectualmente omnipotente. Nuestra mente todo lo puede. Desde entender qué desea el mercado hasta definir quiénes son los más indicados para formar un equipo y cuál debe ser su proceso de trabajo, todo lo resolvemos desde la comodidad de nuestro razonamiento, sin chapotear ni un poco en las iracundas y oscuras aguas de la realidad.

Hoy presencié el final de un sprint. El product owner, concretamente un representante del inversor con cierta experiencia en productos de tecnología, indicaba a diestra y siniestra cómo debía ser la navegación del sitio web y qué resultaría natural para el usuario final y qué no. El equipo ha venido trabajando en el producto a lo largo de seis meses, durante los cuales han recibido permanente retroalimentación de esta misma persona. Han hecho retrospectivas, planificaciones y reuniones diarias. Me preguntan si “hicieron bien scrum”. Yo creo que no, por una simple razón: no tienen ni la más remota idea sobre la verdadera utilidad del producto que construyeron con tanto esmero y precisión. Lo que no logro comprender es cómo este grupo, como tantos otros, consideró que la dinámica de los grupos de trabajo tiene la suficiente complejidad como para encarar la definición de su proceso de una manera empírica y autoorganizada y sin embargo trivializó de tal manera definir qué necesita el mercado y cómo convertir esa necesidad en producto. Por ende decidió obviar cualquier tipo de proceso empírico a la hora de definir qué construir y simplemente hicieron. La semana que viene comienzan sus pruebas de usabilidad. El inversor cruza los dedos. Con suerte entrará en el ínfimo porcentaje de startups que sobreviven, crecen y trascienden. Con suerte esta tarde gano a la lotería.

¿Cuándo deja scrum de ser scrum?

A través de todos estos años en los que he enseñado y trabajado con diversas organizaciones como coach/consultor he ido descubriendo que un conjunto creciente de las prácticas que se presentan en los dos libros originales de scrum2627 han quedado sencillamente obsoletas o directamente nunca tuvieron sentido. He decidido enseñar solamente lo que sé que funciona y considero correcto. Por supuesto que esto difiere ligeramente en cada contexto, pero he encontrado una serie de prácticas que, si bien se encuentran fuera del estándar, me han resultado notablemente efectivas. Algunas podría decirse incluso que difieren radicalmente del canon y de ahí la difícil pregunta (y título de este ensayo): ¿Cuándo deja scrum de ser scrum?28

El product owner es parte del equipo

Mantener una rígida separación entre el PO y el equipo es contraproducente. Lleva indefectiblemente a que se produzcan desavenencias y exacerba la nociva cultura del “ellos y nosotros”. Hace ya largo tiempo que no utilizo la noción de “cerdos y gallinas”, a la que simplemente considero de mal gusto, y en cambio fomento la presencia del representante del producto (¡No lo considero dueño de nada!) también en las reuniones diarias y las retrospectivas. Trabajar de este modo requiere un cambio de mentalidad a todos los niveles, lo que deriva a su vez en una nueva manera de transmitir y adoptar conocimiento. Esto último dista de ser trivial.

Sprints de una o dos semanas

Los sprints de treinta días tal vez tuvieron sentido doce años atrás, cuando scrum fue utilizado por primera vez, pero hoy se hace impensable semejante ritmo de trabajo. También es cierto, al menos en mi experiencia, que los equipos se sienten abrumados ante el pedido de un plan a treinta días, lo que resulta en sprints deficientes. La mayoría de los equipos con los que lo he trabajado aciertan en su estimación a quince días, pero generan un plan vago y confuso para la segunda parte del mes. Lo común es que, tras ocho horas de planificación, cunda el agotamiento y la incertidumbre por lo prolongado del horizonte que se ha delineado. Por último, trabajar en períodos de treinta días significa que un pedido de un cliente puede llegar a demorar hasta sesenta días en completarse. Sencillamente demasiado.

No medir las tareas en horas

Quienes insistan en que los equipos estimen inicialmente sus tareas en horas y actualicen el remanente de forma continua serán indefectiblemente percibidos como microgestores furtivos. En mi experiencia los equipos la consideran una práctica frustrante y carente de todo sentido. Desde 2005 que aliento una mera subdivisión en tareas lo más pequeñas que sea posible. Las tareas deben estar terminadas en una jornada laboral o si no se considera que existe un obstáculo o impedimento, que deberá resaltarse de algún modo. Este enfoque tiene un doble objetivo: primero y principal, facilidad y precisión a la hora de hacer el seguimiento del sprint. En este caso construiremos el gráfico de burndown en tareas en vez de horas, para así poder tener un modo binario de comunicar avance (la tarea está hecha o simplemente no lo está). El segundo objetivo detrás de esta regla será que afloren los obstáculos u obstrucciones que los mismos desarrolladores no logran vislumbrar. Por ejemplo, una tarea puede no haber sido finalizada porque un desarrollador fue abducido por una larga e innecesaria reunión, pero nadie ve esto como un obstáculo porque, al fin y al cabo, “así se trabaja aquí”. Marcar visualmente la dificultad (por ejemplo con un sticker sobre el Post-It que detalla la tarea) muestra a los cuatro vientos qué está sucediendo realmente. Pueden leer el ensayo “Desenterrando impedimentos haciendo incluso menos” para más detalles sobre este enfoque.

Utilizar tableros en vez de hojas de cálculo

Tanto los libros originales como muchos cursos de certificación de scrum promueven el uso de hojas de cálculo u otras herramientas electrónicas para realizar el seguimiento del sprint. Encuentro esto sencillamente terrible. Las hojas de cálculo no sólo ocultan información, sino que incluso mienten descaradamente. La mejor forma de crear transparencia es exponer todo lo que ocurre en enormes gráficas que se encuentren bien visibles, a veces conocidas como irradiadores de información. La lógica netamente colaborativa e interactiva del tablero físico encaja naturalmente con scrum, de un modo que ninguna herramienta electrónica podría jamás hacerlo. Ahora, si esta propuesta te dispara la pregunta “¿Cómo funciona esto con un equipo distribuido?”, quisiera sugerir que el verdadero problema está en la pregunta. Scrum, sin lugar a dudas, alcanza su máxima efectividad con equipos que comparten un espacio físico. La pregunta que nos ayuda es entonces cómo podemos hacer para convertir esta idea en una realidad.

Backlogs en la pared

Otra vez la propuesta es salirse de las herramientas electrónicas, para zambullirnos en el mundo del contacto físico y la realidad palpable. La propuesta es que podamos ver, plasmado en fichas pegadas en una pared de la oficina en la que trabaja el equipo, el trabajo restante con una perspectiva, al menos, de los próximos 3 o 4 sprints. De este modo el equipo puede pensar en el mediano plazo cuando lo sienta necesario. Los backlogs que anticipan mucho más trabajo terminan conteniendo meros recordatorios y podrían considerarse como desperdicio. Cuanto menos tiempo dediquemos a pensar funcionalidades que nunca verán la luz del día, mejor.

Reuniones de estimación

Resulta curioso, pero la estimación no se trata tanto de medir, como sí de aprender. Creo que es útil entender el esfuerzo, pero encuentro mucho más útil llegar a un entendimiento común de un pedido que nos hacen. De hecho, la medida se alcanza como consecuencia de la comprensión y el alineamiento. La estimación debe realizarse inicialmente antes del primer sprint y luego se continúa con regularidad. En mi experiencia una reunión de entre 1 y 2 horas unos 2 o 3 días antes del final del sprint resulta ideal. Existen múltiples maneras de estimar, algunas de las cuales abordaremos más adelante en esta sección. En términos generales encuentro a la estimación más útil cuando se lleva a cabo utilizando una escala relativa (ej. puntos de historia en vez de unidades de tiempo o incluso “días ideales de desarrollo” como se describe en los primeros libros de scrum). La reunión de estimación es una parte integral de un ciclo efectivo de desarrollo. Mantener el backlog de manera visible en la pared le brinda a los desarrolladores la posibilidad de conocer mejor su futuro próximo (ver el punto anterior), promoviendo que las reuniones de estimación sean más breves.

Fuerte foco en prácticas de desarrollo ágil

Que un equipo esté “haciendo scrum” no basta para asumir que sus prácticas de desarrollo van a comenzar a cambiar. Es más, usualmente no lo hacen. Es esencial para un equipo que desee aprovechar scrum hacer lo imposible por introducir desde un comienzo prácticas como las pruebas unitarias automatizadas, la especificación temprana de pruebas de aceptación, el diseño componentizado, el refactoring continúo y el trabajo de a pares. Esto no significa que el cambio deba realizarse de forma abrupta e inmediata, pero no puedo dejar de enfatizar lo crucial que terminan siendo estas prácticas si se desea aprovechar scrum al máximo. El framework en sí no las menciona, lo que lamentablemente se interpreta en muchas organizaciones como que scrum es fácil de implementar, ya que se interpreta como una fina e inocua capa de gestión que se ubica por sobre la forma de desarrollar actual, sea cual sea. He visto este enfoque fracasar tantas veces que ya no tengo la más mínima duda sobre cuán falaz resulta.

El rol del scrum master no siempre es necesario

Un equipo que logra autoorganizarse debería alcanzar la verdadera independencia. Cuando se logra seguir verdaderamente los principios ágiles, distintos tipos de líderes surgirán desde dentro del equipo. En una organización sana el rol del scrum master se transforma en superfluo, lo que no significa que no haya lugar para un estilo de liderazgo ágil en los distintos niveles de la organización. Tal vez un gran problema que tiene el rol del scrum master es que se lo suele ver como una variante del gestor de proyecto. Alguien que dirige a la gente y no alguien que ofrece su ayuda servicialmente. Dado este contexto, tal vez lo que se necesite sea más bien coaching. He visto tantos scrum masters principiantes volver ante la menor duda a sus hábitos de gestión más tradicionales como equipos que aceptan estas recaídas. Estaban acostumbrados a trabajar así y así es la vida. También me produce cierto resquemor el término scrum master. El lenguaje que usamos determina a menudo cómo nos comportamos y este término no ayuda a romper ningún paradigma.

¿Es entonces lo que ofrezco aún scrum? Tal vez lo sea. Creo que sobrevive lo suficiente del flujo original como para poder justificar semejante proclama: permanecen la reunión de planificación, la entrega de software funcionando al final de cada sprint y las retrospectivas. Pero en última instancia el nombre es superfluo. La agilidad que subyace a los principios bajo los cuales enseño y brindo coaching permite que ocurran cambios transcendentales en las organizaciones, que es al fin y al cabo lo que persigo. Si ayuda llamar a eso scrum, pues llamémoslo así. Si ofende, que se llame de otro modo. Eventualmente será, simplemente, “lo que hacemos”.

21 de febrero de 2007

Anexo tendencioso I: Coconstrucción y la soledad del product owner

Existen tal vez dos grandes grupos de product owners exitosos: “el visionario que está en lo cierto” y “el anfitrión explorador”. Más adelante espero profundizar en esta división, pero ahora quiero centrarme en que clases de product owners malos, en cambio, hay muchas, pero tal vez la que más daño y frustraciones ha provocado es la del “PO que cree ser un visionario”. De su existencia nos considero cómplices, por acción u omisión, a todos los que hemos estado difundiendo scrum durante todos estos años. No, salvo casos excepcionales como el del difunto Steve, nadie sabe lo que quiere el mercado. Nadie. Todas son meras hipótesis, muchas de las cuales simplemente están equivocadas. Ni historias de usuario ni requerimientos: experimentos.

No dejen solo a ese product owner, porque fácilmente caerá en delirios de grandeza. Dejen que el equipo diseñe experimentos y ayude a comprobarlos. La palabra final no la tiene el product owner, sino la frustrante y aparentemente caprichosa realidad. Un proyecto entregado a tiempo, según presupuesto y estable técnicamente que no resulta útil es un fracaso. No nos engañemos más, por el bien de nuestros lunes.

Anexo tendencioso II: Los Post-its, una historia de amor (y odio)

No, usar Post-its no significa “hacer scrum”. No, hacer scrum no requiere que usemos Post-its. Hacer scrum implica aceptar nuestros preconceptos y ceder en nuestras posiciones para poder lograr el bien común. Que el árbol que tala 3M no nos tape el bosque de las propias miserias que debemos atravesar para que todo esto tenga sentido. No cambiemos el eje de la conversación, no seamos facilistas.

Proponemos papel porque promueve la toma eficiente de decisiones. Proponemos papel no solo por sus fortalezas, sino por los beneficios que nos traen sus debilidades. No poder obtener fácilmente un reporte nos obliga a preguntarnos para qué demonios lo queríamos de todos modos. Los reportes, como toda documentación, no está prohibida en scrum, sino que simplemente son candidatos obvios a ser considerados grasa

¿Alguien lo usa? ¿Vale la pena el tiempo que invertimos en su creación? ¿Su presencia resalta lo importante o lo oculta tras una nebulosa de colores y flechas? Lo divertido, lo realmente útil, la carne y el hueso está en otro lado.

Anexo tendencioso III: Un buen scrum master pierde su trabajo lo antes posible...o no

Cambiemos el nombre del scrum master. O no, pero que empiecen por fin a hacer lo que deberían, lo que necesitamos de ellos. No queremos secretarios ni policías. No sirven los burócratas de lengua fácil. Nos causan daño los facilistas, los obedientes. El scrum master será un agente de cambio o no será nada.

Así como la billetera mata al galán, el producto siempre derrotará al proceso. La organización es cortoplacista por naturaleza y prefiere una buena hamburguesa a trotar en el parque. Qué importa un poquito de grasa hoy y otro poco mañana.

Alguien tiene que quitarnos la anestesia que causa la inercia. A veces se dice que un buen scrum master pierde su trabajo lo antes posible. En mi opinión, un gran scrum master no quita los impedimentos, sino que cambia el sistema para que no vuelvan a suceder. Es cierto que si un scrum master hace bien su trabajo, nadie se da cuenta que está. Una mosca en la pared, dirían algunos. Pues bien, propongo darle una vuelta de tuerca a la analogía. Libertad le dice a Mafalda con gran sabiduría que “un abejorro no puede parar un tren, pero puede llenar de ronchas al maquinista”. El buen scrum master es un abejorro en la pared. Pica y mucho cuando el tren avanza sin reflexionar ¿Ya picaste al maquinista hoy?

Adición y sustracción en scrum

Día a día me encuentro con dos visiones del mundo en la comunidad scrum que podrían ser resumidas así: i) scrum es maleable y deberá cambiar a medida que sea necesario y ii) scrum es rígido y así debe permanecer29. Los miembros del primer grupo están dispuestos a explorar scrum en cada contexto, para así alterarlo para que cumpla su propósito. Los miembros del segundo grupo se aferran a la simplicidad del primer scrum, creyendo que el framework funciona sin modificaciones en todos los casos. Personalmente ambos enfoques me generan inquietudes.

Considero que existen dos formas de embellecer scrum: una es agregando, la otra es quitando y ambas deben realizarse con extremo cuidado. Suelo estar de acuerdo en que la simplicidad es uno de los fuertes de scrum, por lo que me muestro cauteloso cuando escucho a alguien decir que es necesario agregar roles o definir el proceso con mayor detalle.

Por otro lado me considero un fiel creyente en la permanente búsqueda y remoción del desperdicio, por lo que sistemáticamente dejo de utilizar prácticas propuestas en el scrum “original” si considero que no me agregan valor. Puedo citar el ejemplo de realizar el seguimiento de las horas que insume una tarea (ver también “Cuando scrum deja de ser scrum” y “Desenterrando impedimentos haciendo incluso menos”). Creo que hay otras maneras más simples de saber si el sprint viene o no bien encaminado. Considero que agregamos valor cada vez que liberamos la capacidad creativa del desarrollador. La responsabilidad de actualizar el estado del trabajo y el compromiso con la fecha de entrega siguen ahí, pero el proceso es mucho más simple.

El peligro que conlleva el enfoque “despojado” es que muchos comienzan a razonar en voz alta pronunciando frases como: “Ahora que lo pienso la reunión diaria no agrega valor. Es una pérdida de tiempo, así que mejor dejemos de hacerla”. Esto suele ser una idea muy, pero muy mala ¿Cuándo entonces podemos dejar de utilizar una práctica de scrum sin incurrir en una irresponsabilidad? La respuesta más directa es esta: cuando no estamos descartando la práctica para ocultar una disfunción. He aquí el momento en el que la experiencia marca una diferencia. Una persona con verdadera experiencia con scrum puede evaluar el valor que tiene una práctica en particular, sopesando desventajas y costos de mantenerla o quitarla (como ser una baja en la transparencia), para así poder tomar la mejor decisión posible. Esa decisión, como todas las que tomamos, podrá reconsiderarse en la próxima retrospectiva.

También veo una enorme diferencia entre dejar de lado algunas prácticas y hacer volar el framework por los aires. Creo que el poder entender las sutilezas de las que depende esa diferencia viene solamente con la experiencia. Es posible quitar una práctica si y solo si tenemos alguna forma de obtener ese mismo valor de un modo más conveniente. Por ejemplo, dejar de lado la utilización de días ideales como unidad de medida para no seguir estimando podría no ser la mejor decisión, pero reemplazar la unidad por otro equivalente que permita la estimación relativa, como ser el tamaño de camisetas, parece una buena idea. De este modo mantenemos el valor que nos brindaba la estimación, generando incluso nuevas oportunidades para el diálogo.

En términos generales estoy a favor de simplificar cualquier proceso y en contra de hacer que la cosas se terminen haciendo de un modo más complejo, complicado o menos eficiente. Agregar cosas a scrum suele resultar en complicaciones. Quitar, en cambio, puede resultar en una mayor simplicidad, pero sólo si se realiza con prudencia y un buen entendimiento de los valores y principios de scrum. Si no el resultado será confusión, seguida de un eventual retorno sin gloria a aquello que reinaba antes de que scrum aparezca en escena. Asumamos, con bastante seguridad, que eso no estaba nada, nada bien.

3 de marzo de 2007

Anexo tendencioso I: Una redefinición radical y minimalista del framework (“scrum orgánico”)

A pesar de las infinitas discusiones sobre nimiedades como el nombre de una reunión o la definición de un artefacto, scrum se encuentra definido con bastante precisión. A pesar de ser en espíritu un framework que se opone de raíz a toda clase de procesos prescriptivos de trabajo, su estructura resulta, en mi experiencia, demasiado restrictiva o arbitraria en algunos casos. Tal vez traicionando el espíritu de sus creadores, propongo refundar scrum a partir de una reinterpretación basada en el concepto de crecimiento orgánico.

Scrum orgánico tiene una sola reunión: la retrospectiva. No hay roles ni artefactos, pero sí un enorme cuerpo de doctrina que nos brindará inspiración, retrospectiva a retrospectiva, para poder, de manera incesante, intentar semana a semana mejorar la manera en la que trabajamos.

Cada retrospectiva tendrá dos grandes instancias: revisar los compromisos tomados en la última retrospectiva y decidir próximas acciones en función de aquello que nos duela. Es en esencia lo que podríamos llamar una “facilitación guiada por el dolor”. Si este proceso no frena nunca e inspira los cambios propuestos en el scrum original, mi esperanza es lograr un cambio aún más genuino y, sobre todo, duradero.

Anexo tendencioso II: Sprints, flujo, el cielo y el infierno

Kanban resulta un fenómeno multifacético, que vale la pena analizar. Me gusta dividir a quienes lo prefieren por sobre scrum en dos grandes grupos. La amplísima mayoría de los equipos que he visto inclinarse por el método propuesto por David Anderson lo eligen por una simple razón: comodidad. Estas implementaciones de kanban suelen constar de un tablero y un uso indiscriminado, aparentemente feliz, caótico y cortoplacista del flujo continuo. El sprint, bien entendido, no es ni más ni menos que un límite que permite acotar el caos estratégico. Este límite puede ser excesivo si nuestro dominio es esencialmente caótico o, lo que es lo mismo, inherentemente impredecible. El problema con la mayoría de los equipos que deciden mudarse a kanban es que el caos que desean respaldar es un caos meramente organizacional, salpimentado con una buena dosis de imprevisibilidad producto de un software podrido que de tanta deuda técnica clama a gritos presentarse a concurso de acreedores.

Considero que la evolución natural de un gran equipo ágil es utilizar un flujo continuo. Pero que un grupo que a duras penas se considera a sí mismo equipo, incapaz de la más mínima disciplina, con un producto deficiente técnicamente, en un entorno controlador y salpicado de procesos manuales, quiera utilizar kanban es como pretender aprender inglés antiguo apoyando el televisor sobre un libro de Shakespeare.

Estimación

Los siguientes tres ensayos tratan sobre la estimación aparentemente en total contradicción entre sí. El primero, escrito en 2007, alaba las ventajas de la estimación relativa por sobre aquella hecha utilizando tiempo. El segundo, redactado en 2012, promueve el concepto del “día de equipo”, claramente alineado con la idea de la estimación en tiempos. El tercero, publicado en 2010, condena toda clase de estimación. Lo interesante es que todavía defiendo las tres posturas. El lector sagaz comprenderá que la contradicción es sólo aparente, ya que los tres ensayos respaldan la misma idea central. La estimación puede ser utilizada como una manera de forzar compromiso y obtener “predicciones acertadas”. Otra opción es utilizarla como una manera de generar un diálogo enriquecedor entre los clientes y los desarrolladores. Estos ensayos promueven esta última idea. Lo importante es comprender que la técnica a la que recurramos es irrelevante.

Estimación I: Tamaño

No deja de sorprenderme lo frecuente que resulta encontrarse con agilistas que prefieren estimar en tiempo (ej. horas o días) por sobre la estimación en tamaño (ej. puntos de historia). He llegado a escuchar frases tales como “las implementaciones ágiles más avanzadas utilizan tiempo en sus estimaciones, ya que provee los mejores resultados”. Mi instinto me dice lo contrario, pero mi argumento siempre se parecía a algo tan poco elaborado como “lee a Mike Cohn”, lo que no resulta muy útil en medio de una discusión acalorada ni tampoco contempla los principales argumentos que históricamente he escuchado en contra de la estimación relativa. Lo que sigue a continuación es simplemente un intento de clarificar mis propios pensamientos en la materia. Voy a concentrarme en lo que considero son cuatro argumentos típicos a favor de la estimación en tiempo e intentaré contradecirlos en la medida que me sea posible.

Argumento #1: Estimar en horas permite al desarrollador comparar su estimado contra el esfuerzo real. Estos datos pueden ser utilizados para luego mejorar sus estimaciones futuras.

Este argumento es en principio correcto y funcionará muy bien si el proyecto tiene un sólo desarrollador o si tiene varios, pero cada uno de ellos trabaja en una parte distinta del sistema (un modelo de lo más común en el enfoque “construcción por capas”).

Los problemas se presentan cuando decidimos introducir la idea de equipo multidisciplinario, que trabajará en “tajadas” transaccionales ¿Qué significa una hora-equipo? ¿Tal vez que el equipo completo trabajó durante una hora? ¿O es el tiempo que en promedio le tomaría a un miembro del equipo? Aún sin quererlo estamos hablando del tiempo en términos cada vez más relativos y, por ende, alejados de lo absoluto. Un miembro de equipo podría ser el doble de veloz que sus compañeros, debido a que se encuentra familiarizado con el código o a que posee más experiencia laboral ¿Significará lo mismo una hora para él que para los demás entonces? Claramente no. “Una hora” se convierte en una medida demasiado confusa para medir el trabajo. Ocurre además que distintos miembros del equipo poseen distintas responsabilidades ¿Cómo haremos para encontrar una unidad de tiempo que nos sirva de manera uniforme para medir el trabajo de documentación, diseño de interfaz de usuario, desarrollo y pruebas? ¿Cómo harán para medirse mutuamente entre los integrantes del equipo cuando trabajen en una historia dada? Se ve con claridad que este enfoque se convierte rápidamente en inmanejable.

Algunos equipos ágiles utilizan estimaciones en horas a nivel tarea, bajo la asunción de que un único desarrollador trabajará en una tarea dada. Esto suena razonable, dado que las tareas suelen estar divididas por especialidad, como ser desarrollo del lado del servidor, bases de datos, pruebas, etc. En este caso el Argumento #1 parecería tener validez: los desarrolladores deberían estimar sus tareas en horas y luego mejorar esas estimaciones tras compararlas con el tiempo que realmente les insumió el trabajo. Desafortunadamente este argumento cruje nuevamente si reconocemos que el mejor código (e incluso las mejores pruebas) se construyen de a pares ¿Cuánto significa “una hora” en este caso? ¿Es la hora de la pareja o de cada uno de los individuos? ¿Qué tal si no sabemos de antemano, como suele ocurrir, quién trabajará con quién? ¿Quién estima entonces? ¿Todos? ¿Alguno en particular? ¿Quién tomará semejante responsabilidad?

En términos generales puedo afirmar que estimar las tareas resultan en un desperdicio disparatadamente inconducente. Las tareas deben ser pequeñas y ya. Deberían poder avanzar en el tablero a lo largo de un día laboral. El foco en la estimación debe ponerse al nivel de la historia, ya que es ahí donde radica el valor de negocio.

Argumento #2: Nuestros clientes/product owners no comprenden los puntos de historia. Lo que necesitan saber es cuántas horas trabajan los desarrolladores, para poder saber cuánto va a costar todo esto.

Espero sinceramente que todo aquel que haya leído esa frase encuentre inmediatamente dónde se encuentra el error de razonamiento que subyace a esta frase: microgestión. Ni al product owner ni al cliente le interesa en absoluto cuántas horas trabaja cada desarrollador. Eso rompería al mismo tiempo el encapsulamiento y la autoorganización. Para ser exactos, rompe prácticamente todo lo que hay a su alrededor. Los clientes no deberían comprar horas de desarrollo, sino simplemente software. Su foco por ende debería estar puesto en entender cuánto software pueden esperar recibir para una cierta fecha y luego ajustar el alcance del mismo para poder cumplir esa fecha o mantenerse dentro del presupuesto inicial.

El objetivo de los puntos de historia será entonces ayudar a fijar expectativas. Apenas un equipo ha comenzado a desarrollar iterativamente utilizando una unidad de estimación basada en tamaño, los clientes podrán observar con claridad la capacidad del equipo. Por ejemplo “este equipo puede entregar 40 unidades de software por iteración, por ende necesito priorizar el equivalente a 40 puntos de funcionalidad para la próxima iteración, más algunos puntos de reserva”. Es de una simpleza sobrecogedora. El cliente podrá luego sin mayor esfuerzo mapear puntos de historia a costo, aunque sea de modo aproximado. Lo que menos le debería importar es cuántas horas se tardó en crear su nuevo software.

Argumento #3: Los puntos de historia se van a mapear a tiempo de todos modos y en breve confirmaremos que (por ejemplo) un punto de historia equivale a 2 horas y media, así que mejor salteamos este paso intermedio y medimos directamente en horas

Este argumento falla en un punto básico, ya que supone que el equipo nunca mejora, aun cuando los equipos que se autoorganizan en serio siempre lo hacen. Cuando el equipo comienza tal vez tenga sentido afirmar que un punto de historia equivale a 2 horas y media, pero cuando el grupo refina su forma de trabajo y el código es rescatado del hediondo pozo de lodo en el que se estancó los últimos meses (o incluso años) para elevarse majestuosamente en elegante pose, cuando el mismo equipo reflexiona a intervalos regulares para mejorar su proceso, el valor del punto de historia cambiará. Tal vez ahora valdrá 2 horas, ya que utilizamos el tiempo de forma más eficiente. Ahora el equipo puede comprometerse con seguridad a 50 puntos, en vez de los 40 que podía hasta la iteración pasada.

Más puntos de historia por sprint significa en concreto que el cliente recibirá más software al final de la iteración. El costo de ese software no ha bajado, sino que el equipo que lo construye ha generado mayores ganancias para la empresa y es así como funciona un negocio sano. El cliente está feliz, ya que recibe el software que necesita al precio esperado, pero antes. Todos contentos.

Imaginemos el escenario en el cual el cliente mide los tiempos de desarrollo. Su expectativa lógica sería que el software se abarate cuando el equipo mejore. Lo que antes tomaba 20 horas, ahora toma 10, ya que los desarrolladores invirtieron tiempo en crear una sólida infraestructura y aprender buenas prácticas. Error. Los beneficios de la mejora deberían repartirse al menos en partes iguales entre proveedor y cliente. Un modelo basado en tiempos no permite este reparto sin un (aparente) incremento de precios.

Midiendo en tamaño, por el contrario, permite al equipo mostrar que están entregando más valor por el mismo dinero, asumiendo que su trabajo ha estado priorizado por valor de negocio. Recordemos que una estimación de esfuerzo carece de sentido por sí sola, ya que es solamente una de las dos partes necesarias para calcular el retorno de inversión que necesitamos conocer para conducir un negocio de forma inteligente. Podremos mostrar esta mayor entrega de valor con un gráfico de velocidad. Medir en tiempo no nos habría permitido poner este incremento al descubierto, ya que existe un número fijo de horas por iteración.

Argumento #4: Los puntos de historia no permiten mejorar la técnica de estimación

De hecho, sí que lo hacen. Muchas veces cuando un cliente me pregunta cómo o por qué funciona, les digo que simplemente es mágico, lo cual no está tan lejos de lo que sucede en los hechos. Hasta el momento no he logrado entender cómo o por qué ocurre, pero pasa. Los equipos mejoran su estimación cuando trabajan de este modo, es así. Un simple gráfico de velocidad que muestra dos puntos por iteración (puntos estimados y puntos entregados y aceptados), mostrará una convergencia a medida que pasa el tiempo. Por supuesto que, cuanto más cortas las iteraciones, más rápido nos daremos cuenta que estamos mejorando. Suelo recomendar sprints de una o dos semanas como mucho. Las iteraciones más largas no suelen agregar valor sustancial al proceso.

Por las dudas quisiera aclarar que las dos líneas no se acercan porque el equipo se comprometa cada vez a menos valor, sino que, por el contrario, el promedio de puntos entregados sube, aunque siempre debemos tomar esto con pinzas. Los equipos, si los condicionamos a partir del resultado de sus métricas (por ejemplo con premios y castigos según sea la velocidad que alcancen), burlarán al sistema para obtener los resultados que necesitan, por ejemplo agrandando sus estimaciones. Ésta puede ser una gran tentación, pero ya que el equipo comienza a recolectar datos históricos, deberían corregirse a sí mismos, utilizando sus propia estadística como línea base para futuras mediciones. Recordemos siempre que los buenos desarrolladores quieren construir buen software, del modo más veloz y eficiente que sea posible. Las sospechas y la desconfianza no tienen lugar en un entorno de trabajo genuinamente ágil.

21 de mayo de 2007

Anexo tendencioso: Sépanlo, no saben

Este ensayo es tal vez uno de los menos sustanciosos de todo el libro. Como no podía ser de otra manera, el tema en cuestión es la estimación, agujero negro que todo lo devora ¿Relativa o absoluta¿ ¿Horas, puntos o fresas? ¿Burndown, tareas, equipo, individuo? La comunidad discute en conferencias, los alumnos discuten en los cursos. Todos están desesperados por poder predecir lo impredecible, simplificar lo complejo, negar su ignorancia. No saben ni podrán saberlo jamás. Admítanlo, abracen la humildad.

Estimación II: Tiempo

Las dos unidades más utilizadas en el mundo del desarrollo de software ágil durante los últimos años han sido horas-persona ideales (propio del scrum original) y puntos de historia (XP inicialmente y luego también scrum). Creo que ninguno termina de ser útil. El primero sencillamente porque al software no lo construyen individuos sino equipos y el segundo porque agrega un nivel de indirección hasta poder responder los que los clientes realmente quieren saber: ¿Cuánto van a tardar?

Joshua Kerievsky ha escrito largo y tendido30 sobre las razones por las que él y sus equipos han dejado de utilizar puntos de historia y cómo ha sido el camino que recorrió en ese sentido. En su artículo menciona brevemente el concepto de semanas de equipo:

Suelo aconsejar a los equipos que utilicen historias de usuario y que luego las estimen utilizando “semanas-equipo”: cuánto tiempo le tomaría al equipo completo realizar el trabajo. No importa si sólo 2 personas o los 10 integrantes pueden llevarlo a cabo: solamente denme la estimación como 0.5, 1, 1.5 o 2 semanas de equipo.

En un ambiente ágil que podríamos describir como sano tenemos equipos multidisciplinarios o, lo que es lo mismo, equipos que disponen de todo lo necesario para convertir un concepto en software funcionando. Es poco usual que una sola persona tenga todo el conocimiento necesario, pero sí es probable que un grupo de personas elegidas a conciencia posea esas habilidades entre todos sus integrantes. Se deduce lógicamente que carece de sentido realizar estimaciones en días u horas por persona. Pensar de este modo nos va a dejar parados en una mirada reduccionista, fomentando el traspaso de trabajo a medio terminar entre individuos que desconocen el objetivo final. Como bien señala Kerievsky, no importa si solamente dos personas van a hacer el trabajo, el foco debe ponerse sobre la responsabilidad del equipo completo y de ahí la idea de “semana-equipo” o, mi versión favorita, el “día-equipo”.

No se ha escrito mucho sobre esta unidad de medida, por lo que me alegró sobremanera ver cómo Kerievsky volvió a traerla a la luz. He utilizado esta unidad en muchos equipos a lo largo de los años y, si finalmente decidimos estimar, ésta ha sido la unidad que me ha resultado más útil e informativa. He visto como fomenta un razonamiento realista y genera un mayor compromiso de los miembros del equipo durante los diálogos propios de la planificación. De hecho los desarrolladores son muy buenos estimadores y utilizar días de equipo permite un diálogo más comprometido y respetuoso entre miembros del equipo y los clientes.

Si bien los puntos de historia estimulan el pensamiento en equipo, muchas veces pierden fuerza debido a su alto nivel de abstracción, tan abusado en infinitas conversaciones sin sentido. Me viene a la mente un equipo manipulando el sistema en respuesta a un gerente que reclamaba “más velocidad” ¡Tengamos cuidado con lo que pedimos! Hay dos semanas en un sprint de dos semanas y siete personas en un equipo de siete. Ir más rápido suele significar ir peor.

Tanto las implementaciones de kanban como las de scrum pueden beneficiarse de poder predecir el momento en el que se llegará al mercado. Sabemos que esas predicciones nunca son certeras, pero los departamentos de marketing y ventas tienen que hacer su trabajo, por lo que les debemos nuestro mejor pronóstico. Las estimaciones utilizando “días-equipo” pueden ser rápidas y precisas a la vez, además de brindarnos la posibilidad de calcular fácilmente una fecha de lanzamiento aproximada, utilizando unidades de medida que significan lo mismo para todos los involucrados.

17 de octubre de 2012

Anexo tendencioso: El día que Tobias me enseñó a contradecirme y no morir en el intento

Tiempo atrás me encontraba de visita en la casa de Tobias en Palo Alto, debatiendo sobre un tema espinoso. Lo interesante es que no recuerdo el tema, pero sí mi sonrisa al darme cuenta que él se estaba contradiciendo con algo que había afirmado con gran elocuencia tiempo atrás. Formado en las ciencias exactas, de mente calculadora en mis orígenes, encontrar una contradicción en el argumento del interlocutor era casi un deporte para mi en esa época. Tobias desarmó mi sonrisa con una sola frase:”¿Quién dijo que cambiar de opinión es malo?¿No muestra aprendizaje?”. Gracias.

Estimación III:
No estimarás

La mayoría de los equipos que utilizan scrum hoy en día utilizan las técnicas de estimación descritas en el libro Agile Estimation and Planning31 de Mike Cohn. En resumidas cuentas esto significa estimar historias de usuario (o sea, pedidos/requerimientos) en tamaño relativo utilizando puntos de historia y estimar tareas en horas. Hace más de un lustro que no estimo tareas, aunque solo en los últimos dos o tres años he visto evidencia que muestra el poco valor que tiene la estimación de historias. Llevarla a cabo toma tiempo, demanda un esfuerzo innecesario y sirve de poco para mejorar la capacidad de un equipo de comprometerse y luego cumplir con ese compromiso. En ocasiones, incluso, causa irritación y angustia tanto en los equipos como en los clientes, quienes no logran ver valor alguno en la práctica.

Suelo estar a favor de que los equipos y los individuos que los conforman sientan una incomodidad pasajera, llegando incluso al eventual ataque de nervios. Esto suele ser una parte importante del proceso de aprendizaje, pero en el caso de la estimación no he visto que este sufrimiento valga la pena. Considero que hay cosas más útiles en las que enfocarse, como ser una mejora en la redacción de las historias de usuario, para que posean por fin un claro valor de negocio y obviamente un criterio de aceptación. El mero diálogo que lleva a definir estas condiciones conduce a generar requerimientos más pequeños. No es fácil crear y acordar un criterio de aceptación para pedidos enormes y vagos.

Si la velocidad es importante (y no creo que lo sea), entonces podemos calcularla contando la cantidad de pedidos entregados. Cuando los pedidos son pequeños, tienden a tener todos un tamaño similar. Si no lo son, esto indica una falta de claridad en dos frentes: aquello que pide el cliente o product owner y aquello a lo que se compromete el equipo. Creo que vale la pena invertir un poco del tiempo del sprint en tener un mejor backlog, desafiar la manera de pensar las cosas y refactorizar el pedido, convirtiéndolo en una serie de pedidos más pequeños. Siempre recomiendo a los equipos que se comprometan a un conjunto de entre 5 y 10 historias por sprint. Este número parece funcionar independientemente de la duración del sprint o del dominio de aplicación. Tener pedidos más pequeños también ayuda en el proceso de priorización, ya que decidimos con mayor facilidad qué es lo que no se debe realizar.

Recientemente he llegado a la conclusión de que usar un sistema de estimación que utilice números, sean horas ideales o puntos relativos (que en definitiva tendrán una correlación con tiempo), es una manera más de acatar un modelo de pensamiento caduco, una forma de apaciguar las ansias de gerentes y líderes del antiguo régimen, de la vieja escuela, que son incapaces de, o mejor dicho no están dispuestos a, pensar más allá de puntos, datos y promesas vacías. Por más lamentable que sea, en el mundo ágil sigue con vida la mirada, que siempre existió en el universo de la gestión de proyectos, que propone que los equipos deberían ser capaces de, como sea, comprometerse a la fatal combinación de tiempo y alcance. La estimación del modo en que la hacemos comúnmente no hace sino perpetuar ese mito. Y si no lo hiciera, al menos no lo desafía.

Cualquier equipo se beneficiará más de una estimación intuitiva que en una basada en datos numéricos. Somos seres tan sentimentales como pensantes; irónicamente tal vez los primero sea más importante que lo segundo en el trabajo del conocimiento. Al concluir una reunión de planificación el equipo debería preguntarse en voz alta: “¿Estamos profundamente convencidos de que podremos cumplir con el compromiso asumido?”. Si la respuesta no es un “¡Sí!” contundente y convencido, entonces creo que el equipo debería reducir su compromiso hasta estar en condiciones de responder de este modo. Sé lo que están pensando, pero no, esto no produce equipos lentos que trabajan por debajo de su capacidad. Nunca he vivido algo así. Creo que si a alguien sí le ocurre, es probable que haya otras disfuncionalidades organizacionales mucho más profundas con las que habría que lidiar primero.

Si logramos dejar de lado la obsesión por los números, comenzaremos por fin a confiar en nuestro instinto, aprovechar nuestra experiencia y la sabiduría colectiva que anida en nuestro equipo, para así poder dar una respuesta sincera y más precisa a la respuesta “¿Para cuándo?”.

Si sienten que su equipo está parado en una mentalidad esclava de la estimación, los desafío a dejar de lado cualquier tipo de estimación durante algunos sprints, poniendo el foco en hacer que las historias de su backlog sean más pequeñas, dejen claro cuál es su valor y tengan criterios razonables de aceptación. Tal vez se lleven una grata sorpresa cuando vean lo que termina ocurriendo.

24 de enero de 2010

Anexo tendencioso: Todo es mentira, mentira es el lamento

El movimiento #NoEstimates me atrae, no necesariamente porque acuerde con todo lo que afirman, sino sobre todo porque se animaron a desafiar un verdadero templo del viejo paradigma. La estimación como ejercicio puede ser útil, pero antes debemos despojarnos de una buena cantidad de grasa que habita en las maneras en las que estimamos hoy en día, incluso en el mundo ágil ¿Por qué tanto énfasis en la estimación, aun sabiendo que suele estar errada?¿Por qué será que cada vez que hablamos de estimación, asumimos que estamos hablando del costo de un desarrollo y no del valor que éste genera?¿Por qué, conociendo de memoria el cono de la incertidumbre, seguimos comunicando nuestras estimaciones como valores (“1 de diciembre”) y no como rangos (“entre octubre y febrero”) que se afinan con el tiempo?

La idea no es dejar de estimar, sino hacerlo de una manera más inteligente, más pragmática. Lo que buscamos en definitiva es saber si el proyecto que encaramos tiene algo de sentido o no, para luego refinar nuestro backlog iterativamente, hasta obtener historias pequeñas, aproximadamente del mismo tamaño. Todo lo demás es, creo yo, grasa.

Los roles en scrum:
una abstracción

Scrum fue diseñado originalmente con el desarrollo de software en mente, pero la experiencia me ha demostrado que puede ser aplicado en numerosos escenarios laborales, siempre y cuando los valores y principios subyacentes hayan sido comprendidos. Sin embargo he comprobado que, al intentar explicar scrum en un contexto más general, me siento incómodo manteniendo los nombres originales, sea porque los siento demasiado propios del mundo del software, sea porque ya se encuentran asociados a una implementación en particular que suele ser poco satisfactoria. Con la intención de describir scrum de un modo más agnóstico he decidido intentar repensar desde cero los nombres de los roles en este ensayo, con el objetivo de que estén aún más cerca de su verdadera esencia.

Los roles del scrum agnóstico

La voz del “Qué”

Una única voz, posiblemente como canalizador de otras tantas voces, cuyo objetivo será definir qué es un “resultado adecuado” y priorizar el trabajo con el objetivo de obtener el mayor valor posible dado el actual contexto. La voz del “Qué” también es responsable del presupuesto y la eventual de decisión de continuar o cancelar el proyecto.

La tribu del “Cómo”

Un grupo funcional de entre tres y siete personas, que entre todos poseen las habilidades necesarias para resolver los problemas planteados por la voz. Solo los miembros de la tribu tienen la potestad para tomar decisiones sobre cómo se lleva a cabo el trabajo, siempre reclamando claridad y apoyo de la voz según sea necesario.

El comodín (o el bufón)

He aquí un facilitador despojado de todo interés en el resultado en sí, enfocado obsesivamente en lograr un ambiente de trabajo genuinamente colaborativo. El comodín intentará guiar a la tribu hacia las tierras de la reflexión, la mejora continua y la autosuficiencia. Instará de modo desafiante a la organización que la contiene a liberarse por fin de tanto control y desconfianza, para abrazar nuevos modos de liderazgo, basados en el honor y la libertad.

El comodín, la carta independiente, suelta, sin compromiso preestablecido alguno, actúa como un servidor de la tribu y como agente de cambio dentro de la organización. La idea del comodín viene del mundo del Teatro del Oprimido, creado por Augusto Boal32.

El término no ha tenido la mejor recepción en el mundo corporativo, lo cual no hace sino alegrarme, pero estoy abierto a otras ideas. David Koontz sugirió el término “bufón”, recordando que el bufón solía ser el único que podía decirle una verdad al rey y vivir para contarlo. Sea cual sea el nombre que elijamos, considero que deberá reflejar su espíritu agnóstico, brutalmente honesto aunque sanador, quitando por ende del medio el término “master”.

Estos tres roles constituyen un equipo scrum. Su capacidad para mirar el mundo desde distintas perspectivas, defendiendo por ende distintos intereses (rentabilidad, excelencia y bienestar respectivamente), es lo que genera la dosis sana de conflicto y tensión que se requiere para alcanzar niveles superiores de innovación, creatividad y valor agregado.

Existe un cuarto rol en scrum, por fuera del equipo, pero que se involucra regularmente en la dinámica de trabajo. Este rol lo ocupa, básicamente, cualquiera a quien le importe lo que haga este equipo.

El público

Aquí se encuentran representados aquellos que financien, utilicen o se beneficien del producto, servicio o idea que estamos creando. El público opina, reacciona, retroalimenta a intervalos regulares, por lo que sería ideal que entre ellos exista una mirada eventualmente crítica. El término “público” utilizado en este contexto fue acuñado por Matt Heusser y Chris McMahon en un ensayo titulado “Performing the Software”33.

El “Qué” es el destino, el “Cómo” es el camino

Al denominar al primero de los roles la voz del “Qué” y al segundo la tribu del “Cómo”, en seguida separamos radicalmente entre sí los dos aspectos que conforman cualquier proceso creativo. La distinción entre el Qué y el Cómo separa los pasos pero no debe de ninguna manera separar a los actores. Sigue siendo vital que exista un diálogo constructivo entre quien pide y quien responde. Pedir no es lo mismo que demandar, ya que solo en el primer caso estamos abiertos a escuchar contraofertas.

Para que la autoorganización funcione necesitamos haberle conferido las suficientes facultades al equipo y haber confiado en su capacidad. Es difícil confiar si los pedidos son difusos y es ridículo pensar en haber conferido facultades si permanentemente interrumpimos (o dejamos que ocurran interrupciones) con el objetivo de interferir en la tecnología, herramientas y prácticas que se utilizan.

Necesitamos una separación clara entre el valor solicitado y el camino que se tomará para producir ese valor. Quienes se encuentran del lado del negocio deben definir los resultados esperados, describiendo audiencia y valor. Dado que seguramente no sean ellos quienes vayan a desarrollar las soluciones, necesitan mantenerse completamente al margen del camino que será recorrido para la implementación, salvo que se los invite a participar.

Poder observar los roles de scrum desde esta mirada algo más agnóstica nos permite vislumbrar con mayor claridad los principios subyacentes necesarios para que el framework funcione como debería. No deja de sorprenderme lo fácil que resulta perder el foco en las decisiones cotidianas de implementación, dejando de lado el propósito superior original.

8 de octubre de 2009

Anexo tendencioso: Mis nombres

Definitivamente algo no funciona con los nombres elegidos para cubrir los roles en scrum. Los términos elegidos por Tobias son excelentes, no solo como tales, sino como disparadores de la discusión. Lo que vengo a ofrecer no es ni más ni menos que una simple alternativa, con el objetivo de continuar el debate.

“La voz del Qué” me habría parecido intachable allá por 2009, pero siento que el concepto de product owner ha evolucionado en los últimos años. Hoy en día se destacan tres aspectos que poco figuran en este término. Los mejores product owners no hablan en nombre del público, sino que más bien se convierten en eficaces “anfitriones” de conversaciones efectivas entre el equipo y el público. Los mejores equipos no se conforman con que alguien les diga qué hay que hacer, sino que exigen conocer antes el “Por Qué” y desarrollan luego de manera colaborativa el “Qué”. De hecho los mejores equipos saben que cualquier “Qué” no es más que una hipótesis, que deberá ser comprobada en el mundo real por medio de un “experimento”. Admito que es un poco largo, pero me quedo con “anfitrión empírico del Porqué”.

Con respecto a “tribu”, el cambio que propongo es meramente estilístico. Una tribu no da a entender apertura, sino más bien una tendencia al aislamiento. Prefiero en este caso la analogía del “ensemble”, mucho más ligado al proceso creativo y la colaboración.

Por último, no conozco agilista que no admita que el término scrum master es no solo paradójico, sino simplemente anacrónico. Como ya comenté anteriormente, disfruto mucho de la analogía que representa el término “abejorro en la pared”. “Catalizador del kaizen” o “catalizador” a secas son alternativas poderosas y tal vez más universales.

Los nombres parecen meros detalles decorativos, pero transmiten un mensaje, una cosmovisión, allí donde las explicaciones no llegan. Un buen nombre puede convertirse en el mejor meme, haciendo las veces de embajador del cambio que queremos difundir. Sigamos pensando, sigamos repensando, que vale la pena.

Scrum no hace nada

La frase “hacer scrum” tiene tan poco sentido (y es tan imposible) como pretender crear una instancia de una clase abstracta. Scrum es un framework que permite que emerjan disfunciones organizacionales. No es ni un proceso ni es prescriptivo. El framework scrum, tal como fue descripto en los primeros libros de Ken Schwaber, en el Agile Atlas de la Scrum Alliance34 y en tantos otros sitios, no puede hacer nada en concreto por sí solo. Es, en cierto sentido, un contrato establecido entre quienes buscan un cierto valor y aquellos que lo construirán. Entendamos que un contrato no construye nada. Una interfaz es pasiva y no termina produciendo nada concreto sin una implementación que la haga realidad.

Scrum recién comienza a funcionar cuando se lo comprende con la suficiente profundidad como para crear una implementación concreta, que permitirá a su vez que emerja un proceso propio, particular. Entender y respetar el framework que propone scrum y la serie de lineamientos que lo acompañan nos permitirá estar alineados, sobre todo a base de un conjunto compartido de valores y principios, a partir de los cuales trabajaremos día a día.

Scrum en sí puede ser visto como las reglas de un juego. Ken Schwaber utiliza a menudo la analogía del ajedrez: reglas que se comprenden rápido, lo que permite comenzar a jugar junto a otros casi de inmediato. Romper alguna de sus reglas rompe con el juego por completo, lo que hará difícil que encontremos un oponente con el cual jugar. El problema con esta analogía es que el ajedrez es una actividad competitiva y scrum no lo es, por lo que prefiero otras metáforas, como ser la de la danza. Un baile en pareja, como el tango, requiere que ambos bailarines sigan ciertas reglas básicas. Habrá un ritmo, pasos y posturas que respetar. Una vez que dominamos lo básico, podremos improvisar, siempre dentro de un marco preestablecido. Las reglas del tango atan a la pareja a un sendero de búsqueda permanente de la excelencia. Será por medio de la creatividad que se podrá recorrer el camino que va del ejercicio predecible, casi numérico, hasta convertir sus pasos en un objeto de pasión y belleza. En scrum necesitamos bailar junto a otros. Es hacer, no saber, lo que da resultados. Scrum, como el tango, requiere que nos relacionemos, improvisemos, nos arriesguemos, escuchemos y, por sobre todas las cosas, confiemos.

Respetando el contrato, las reglas (la interfaz en la jerga del software), nos permitirá crear una forma de trabajo que se adapte a nuestro contexto. El contexto incluye la gente, el sector, la organización, el mercado, el producto, nuestra ubicación geográfica, nuestra cultura, idioma, entorno físico y hasta historia. Eso sí, el principal aspecto será siempre el humano. Otra manera de decir lo mismo es afirmar que scrum no hace nada, la que hace cosas en definitiva es la gente. El proceso emergerá a partir de la interacción entre aquellos que trabajen juntos día a día y será diferente para cada organización y equipo. He aquí donde tantos tropiezan, ya que creen que la creación del proceso propio empieza rompiendo las reglas. Nada más lejos de la realidad. Comenzar así es fallar antes de siquiera arrancar.

El proceso scrum que una organización construye debe operar bajo una serie de parámetros básicos, unas reglas ya acordadas. Para utilizar una analogía del diseño de software, deben implementarse todos y cada uno de los métodos de una clase abstracta para que el programa compile. Si intentamos mover el alfil en línea recta, nuestro contrincante va a levantarse y dejar la mesa más bien ofuscado. Si tomamos la pelota con la mano en un partido de fútbol, recibiremos una bonita tarjeta.

El marco de trabajo que presenta scrum es un mecanismo muy poderoso para que emerjan disfunciones personales y organizacionales. Es justamente ese poder el que hace que tantos intenten eludir las reglas, tomar atajos. Es lógico que no quieran ver. Pero no mirar no logra que los problemas dejen de existir, que aquello que está roto se arregle. A lo sumo prolongará lo inevitable, generalmente aumentando la gravedad del impacto. No es por nada que destacamos la importancia del coraje en scrum.

Comparar scrum con prácticas propias de una implementación, como ser XP o el Software Craftmanship, carece de sentido. Estos movimientos ofrecen excelentes herramientas para llevar adelante una implementación de scrum, para convertir lo abstracto en concreto. Scrum apenas ofrece un sólido marco, apuntalado por un ritmo implacable, que permite sacudirse el polvo acumulado durante años.

No se puede “hacer scrum”, solamente abrazarlo. A mayor valentía, mayor será la solidez del proceso que emerja.

11 de octubre de 2009

Anexo tendencioso: Analogías que duelen

Este anexo no sólo apunta a ser tendencioso, sino también un poco polémico. Alistair Cockburn ha enriquecido sistemáticamente el universo de conceptos que utilizamos en el mundo ágil. Somos muchos los que día a día usamos términos de su autoría tan claros y contundentes como “irradiación de la información”, “temperatura de la comunicación” o “flujo de decisiones”. Aprecio muchísimo a Alistair y a sus ideas, pero considero que una en particular nos ha llevado por mal camino. El concepto de ShuHaRi, tomado por el mundo ágil de la práctica del Aikido pero originado en el teatro Noh varios siglos antes35, así como la analogía que presenta Tobias con el tango o Ken Schwaber con el ajedrez, sirven, ayudan, pero también fomentan el rechazo. Paso a explicar por qué.

Para el recién llegado tenemos supuestamente la receta perfecta, la solución tranquilizadora: el modo Shu. Repita la práctica hasta comprender su esencia y dominar la técnica, para luego poder trascenderla. El problema en mi opinión no está en el modelo, sino en una premisa que considero errónea en muchos casos. Cuando alguien comienza a practicar Aikido, bailar tango o jugar al ajedrez, lo hace voluntariamente y su objetivo es justamente ser un buen ejecutante. Son pocos en cambio los que practican scrum para ser mejores en scrum. La gente utiliza scrum como un simple medio, sueña con sacárselo de encima lo antes posible, no pone en juego el más mínimo deseo de practicarlo correctamente y comprender su esencia. Sencillamente no les interesa, no les apasiona y eso está bien, no tiene por qué. Scrum debe ayudar a las personas, equipos y organizaciones a agregar cada vez más valor, entregar productos de mayor calidad y aumentar la satisfacción laboral y del cliente. Valor, calidad y satisfacción. Si el mundo pudiera, lograría eso sin scrum.

¿La solución? Yo cambiaría el enfoque, partiendo más bien de la motivación de quienes vayan a adoptarlo. Esa es la idea detrás del crecimiento orgánico guiado por el dolor. Comenzar con retrospectivas y agregar una práctica de forma experimental como respuesta a un dolor admitido y comprendido de forma sistemática y frecuente. Cultivemos scrum y reguémoslo con amor y disciplina. No enseñemos scrum, no lo prescribamos, seamos meros jardineros.36

Matrimonio, pero

Se ha popularizado últimamente el término “ScrumPero”37 (“Sí, hacemos scrum, pero...”), que hace referencia a aquellas implementaciones de scrum que no cumplen con el framework en su totalidad. ScrumPero es una de las causas más comunes de la falta de arraigo y resultados del framework y deja el terreno listo para que quienes lo practican digan abiertamente que “scrum no funciona”. Probemos abrir la mente y ver el problema desde otra perspectiva. Las formas de trabajo o de ser suelen dejar de ser efectivas cuando el marco de trabajo que fue diseñado para respaldarlos es ignorado o al menos puesto en segundo plano. Este ensayo analizará desde esta mirada un framework muy conocido y utilizado: el matrimonio.

El matrimonio es un concepto fenomenal. Se trata de la promesa de amor, unión, compañerismo, solidaridad, cuidado mutuo y construcción de una familia. Existe en todas las culturas de una u otra forma y resulta atractivo para una buena cantidad de gente, siempre a partir la ilusión del amor a largo plazo y las grandes promesas cumplidas.

Y a pesar de todo, muchos matrimonios fracasan. Muchísimos ¿Por qué será? Hay, obviamente, infinidad de razones, pero casi siempre se puede decir que lo que ha ocurrido es que las condiciones (reglas, si no les molesta) para hacer que un matrimonio funcione son dejadas de lado o simplemente reformuladas para acomodarse a las necesidades de uno de los individuos que lo componen. Si prestamos mucha atención a la manera en la que se expresan algunos cónyuges, podremos leer entre líneas frases como “El amor está muy bien, pero este tema del honor no me termina de cuadrar”, “Hasta la muerte suena a, digamos, demasiado tiempo”, “Fidelidad equivale a no contar lo ocurrido, al fin y al cabo”, “Veo valor en la parte de ‘en la salud’, pero lo de ‘en la enfermedad’ no parece contribuir a mi felicidad personal”, “¿Podría reformular esa parte como ‘en la riqueza o en la no tan riqueza’? Si estabas pensando humillarme llevándome a la pobreza, te dejo aquí” y así.

MatrimonioPero. Es sin dudas la causa número uno por la que fracasan: la incapacidad o negativa a honrar el contrato. El contrato al fin y al cabo es muy simple y existen distintas opciones, así que tampoco podemos decir que nos obligaron a jurar por algo en lo que no creíamos. Aceptamos vivir de acuerdo al marco establecido, pero cuando el horizonte comienza a ponerse gris, uno o ambos miembros de la pareja empieza a torcer las reglas para acomodarlas a su nueva realidad, socavando las bases y, en última instancia, causando que la estructura termine desmoronándose. Habiendo participado de un fracaso matrimonial, no digo esto como conjetura, sino desde una perspectiva de dolorosa reflexión.

Calculo que la pregunta pertinente para resumir este ensayo sería: ¿Puede fracasar el matrimonio? Quisiera sostener enfáticamente que “el matrimonio” nunca falla. El matrimonio visto como mero framework, como una promesa, es robusto a mi entender. Le ha funcionado a la humanidad durante cientos de siglos. Existen pequeños ajustes y mejoras paulatinas que hemos hecho (ej. haber quitado la palabra “obedecer” del texto que repite la mujer en muchas ceremonias cristianas), pero la mayor parte del framework se ha mantenido incólume durante ya bastante tiempo.

Lo que sí fracasan son algunas instancias, algunas implementaciones individuales del matrimonio. Son pocos los que han vivido un matrimonio fracasado y luego consideran que el concepto en sí está equivocado. Echarán culpas entre ambas partes o a agentes externos (ej. la familia política), pero eventualmente seguirán con su vida y muchas veces experimentarán con una nueva implementación, aprovechando todo lo aprendido en sus experiencias anteriores.

El matrimonio no fracasa, algunos matrimonios sí lo hacen. Es importante separar el modelo de las implementaciones, tanto en este como en otros aspectos de nuestras vidas. Si construyo una casa yo mismo utilizando materiales de mala calidad y técnicas mediocres, ¿podré decir que el concepto “casa” está errado? Si tenemos individuos hipócritas y deshonestos liderando el gobierno, ¿eso convierte al concepto “democracia” en un fracaso? Creo que cualquiera estaría de acuerdo en que el problema está más en la implementación que en la idea.

Tantos se apuran en criticar el concepto de autoorganización, describiéndolo como una moda pasajera, o tal vez a scrum como un modelo demasiado rígido, señalando algunas implementaciones fracasadas para desacreditar los conceptos. Lo que no comprenden es que en su esencia los conceptos de scrum son valiosos. No solo hablan de nuestros ritmos más naturales, sino sobre todo de esa necesidad tan humana de colaborar y confiar. Scrum, como el matrimonio, es un contrato basado en valores de lo más sensatos. Ambos traen consigo la promesa de una mejor calidad de vida. Sí, metemos la pata bien seguido, pero eso no quita que las ideas sigan siendo sólidas y memorables.

3 de mayo de 2011

Anexo tendencioso: Sí y además

Esta vez la analogía funcionó. Utilizar el matrimonio como modelo que “no falla” cumple con su cometido. Es ridículo echarle la culpa al framework si no cumplí con sus reglas más básicas. Es de necio acribillar al mensajero.

Quisiera de todos modos agregar un comentario, una nota. Este framework podría llegar a fallar. Si bien es cierto que la mayoría de las implementaciones de scrum que conocí fallaban en respetar el espíritu más básico, tenemos que admitir que el framework es relativamente reciente. Tal vez se pueda inspeccionar y adaptar producto y proceso, pero con diferentes cadencias. Tal vez no siempre sea conveniente que haya una única cabeza responsable de priorizar. Tal vez, solamente tal vez. No lo descartemos. Las sagradas escrituras se equivocan. Las constituciones se equivocan. Scrum tal vez también.

No tengas reuniones

Recientemente, mientras me encontraba dictando un taller introductorio sobre scrum, llegué a la súbita conclusión de que no quería usar la palabra “reunión” cuando describía el framework. Las reuniones tienen bien ganada su pésima reputación. Recuerdo interminables reuniones, de horas y horas, donde la cosa no avanzaba, los más locuaces argumentando sin fin, rumiando, cavando trincheras cada vez más profundas, mientras los más introvertidos, avergonzados, con la mirada perdida, fija en la mesa o la pared, deseando estar en su cubículo, haciendo cosas bastante más útiles.

Si bien es cierto que scrum ha reducido el tiempo invertido en reunirse a unas pocos momentos clave y con tiempos máximos bien definidos, el triste legado que nos llega de la “cultura de la reunionitis” aún cuelga sobre nosotros, cual espada de Damocles. “Scrum tiene demasiadas reuniones” es una de las quejas que más seguido escucho. Suele darse la coincidencia de que quien se queja tiene reuniones diarias que duran más de 40 minutos, sufre interminables retrospectivas improductivas, superficiales o meramente catárticas, mientras que las reuniones de planificación son manipuladas y unilaterales, de las que el equipo sale entre taciturno y deprimido.

Es así como en ese mismo momento se me ocurrió que decirle a los participantes del taller que “las reuniones son esenciales en scrum” iba a ser más desmoralizador que emocionante. Lamentablemente la cultura de la reunionitis ha penetrado también en scrum. Algo tan opresivo, tan pesado, tan arraigado en nuestra forma de ser, aplastará indefectiblemente cualquier cosa que intente ponerse en su camino y desafiar su poder. La Scrum Alliance introdujo el término “ceremonia” para reemplazar “reunión”, pero creo que es casi igual de dañino o hasta incluso peor. A más de uno le trae imágenes de cultos secretos y siluetas amenazantes llevando a cabo rituales inimaginables. Usar ese término en la misma oración que scrum master ya sería demasiado.

Es así como decidí utilizar el concepto de “conversación”. Scrum está enfocado fuertemente en las personas y las personas a su vez tienen conversaciones. Durante esas conversaciones planifican, se alinean y reflexionan. Tendremos conversaciones cuando sea apropiado y durante el tiempo adecuado, para así poder informar sobre el trabajo realizado. Si no tenemos esas conversaciones no sabremos qué tenemos que hacer (planificación), hacia dónde estamos yendo (alineamiento durante la revisión/demo) y repetiremos hasta el infinito nuestros errores (reflexión durante la retrospectiva). Habiendo usado ese término, percibí un mayor interés en la sala, un mundo de corazones aliviados. Básicamente acababa de decirle a este grupo que nunca más tendrían una reunión sin sentido.

Dejemos de hablar de reuniones. De hecho, mejor dejemos de tener reuniones. Es demasiado poco lo que hemos obtenido de ellas como para seguir insistiendo. Eso sí, que la gente se junte para mantener un diálogo colaborativo, eso es tan emocionante como productivo.

25 de marzo de 2011

Anexo tendencioso: Los nombres, siempre los nombres

Los nombres comunican el resumen de una idea, son memes por naturaleza. La palabra reunión no solamente es problemática por las asociaciones que produce, sino por su semántica más esencial. Reunir implica juntar algo que se separó. Es una acción física, en la que distintos objetos son movidos, trasladados, usualmente por un tercero. Quienes asisten a una reunión cumplen con la definición implícita del término al pasar la puerta y ocupar un espacio físico. Llego, me siento y listo, cumplí con el objetivo. Puedo poner mi mente en blanco o incluso revisar el correo y nadie debería ofenderse.

El término conversación se refiere en cambio a un grupo de personas en acción, hablando y escuchando, intercambiando ideas, o al menos palabras. Se acerca mucho más al espíritu del encuentro, al menos en mi opinión. La pregunta ahora es si alcanza con cambiar el nombre. Tal vez sea un poco tarde para que solo eso baste.

Si nunca participaron de un Open Space38, deberían. Podríamos definirlo como una conversación autónomamente distribuida para masas. Cualquiera podría decir que una organización vive, día a día, entre salas y máquinas de café, un Open Space, casi siempre fallido. Además de una estructura para el armado de agenda que no viene al caso, Open Space tiene una única regla: “la regla de los dos pies”. Si la conversación en la que estoy no me aporta valor y yo no estoy aportando valor, mi obligación es usar mis dos pies y buscar mi destino por otros lares. Si les suena rudo, pueden agregarle a la regla que, antes de irme, debo resumirle al resto la razón de mi partida en una oración. “El tema del que están discutiendo no me aporta” es un ejemplo completamente válido. Anímense a dejar que la regla ayude a detectar qué reuniones no son conversaciones. Si una persona no está interesada en una charla, preguntémosle por qué y entendamos sus razones. Lo que seguro, seguro, seguro no funciona es obligarla a quedarse.

Timebox != Compromiso

Érase una tarde de pura procrastinación, invertida por completo en la lectura de un torrente de tweets sobre el concepto de timeboxing. No podía sino fascinarme el nivel de desprecio que se descargaba sobre una simple unidad de tiempo. Se le echaba en cara la baja calidad del trabajo y del resultado, el estado de pánico de quienes lo utilizaban y tantos otros comportamientos disfuncionales.

Ya habiéndome resignado a no cumplir con al menos una de las obligaciones que tenía en ese momento, me zambullí en el torrente con el fin de desafiar este punto de vista. Luego de un par de intercambios de opinión, me di cuenta que el desprecio no provenía de ninguna característica propia del timeboxing, sino más bien de aquello con lo que mucha gente lo confunde.

Parecería ser que algunos entienden al timeboxing más o menos de este modo:

Definir una duración

Comprometerse a una cierta cantidad de trabajo

Darse cuenta que no se llega con el compromiso

Apurarse para terminar de todos modos

Generar resultados de mala calidad

Terminar exhausto

Volver a #2 – repetir hasta morir o entrar en bancarrota

La realidad es que el único paso que tiene algo que ver con el verdadero timeboxing es el #1. El resto no es ni más ni menos la dinámica psicótica de hacer promesas incumplibles, una y otra vez. Los antagonistas del timeboxing llaman a esto “compromiso”.

He aquí cómo entiendo yo al timeboxing:

Definir una duración

Dialogar con el solicitante. Revisar y preparar los pedidos. Priorizar.

Seleccionar un pedido lo suficientemente pequeño para entrar en el timebox

Completar el pedido, con la calidad suficiente para satisfacer las necesidades del solicitante.

Respirar [reevaluar pedidos restantes si corresponde]

Volver a #3 - hasta que no haya pedidos que entren en el tiempo restante

Dejar de trabajar [si sobra tiempo, holgazanear brevemente39]

Reflexionar. Aprender de los errores y adaptarse en consecuencia.

Volver a #2 – repetir hasta cumplir con todos los pedidos o alcanzar fecha límite

No es sencillo llegar a la esencia de este pseudocódigo, pero creo que tiene una mínima claridad. Sigue existiendo compromiso, pero estamos hablando de un compromiso razonable, no artificial. La cantidad de trabajo al que nos comprometemos es independiente de la longitud del timebox, cuyo objetivo no es ni más ni menos que crear ritmo, dar espacio. Es un latido y no otra cosa. La vida rebosa de ritmos; encontrar el nuestro y poder honrarlo es algo hermoso. Eso sí, requiere soltar un poco tanto control.

Si estás utilizando un timebox para forzar compromisos contra fechas impuestas desde el exterior (y no hay un cambio en la forma de hacer las cosas cuando esto se transparenta), entonces tal vez el foco está puesto en el lugar equivocado. Es fácil seguir culpando al timeboxing, sacándose de encima la responsabilidad que nos compete. La otra opción consiste en juntar coraje, para luego mirar hacia dentro, entendiendo y aceptando quiénes somos, qué podemos y, sobre todo, qué no.

20 de abril de 2012

Anexo tendencioso: Pronóstico, sólo un pronóstico

Hace poco Alistair Cockburn me comentaba, parafraseando, que todos los equipos que trabajan con iteraciones son un poco disfuncionales. Profundicemos.

Los hay en extremo conservadores, sobre todo en organizaciones donde el error se castiga con facilidad. Estos son equipos cautelosos, que abusan del proceso de estimación con la esperanza de alcanzar la predicción perfecta. Ante la duda, claro está, subestiman su capacidad.

Los hay en cambio audaces, omnipotentes hasta la ceguera. Algunos los llaman optimistas o incluso necios. Estos equipos fallan una y otra vez en sus estimaciones, pero su orgullo permanece inmutable. “Las circunstancias fueron complejas, ¿qué esperaban?”, parecen decir con la mirada mientras el resto de la organización escucha atónita.

Parecería ser entonces que el trabajo con iteraciones está condenado al fracaso. Y sin embargo sigo confiando en él. Tiene un techo, es cierto, pero hace las veces de fenomenal muleta para equipos y organizaciones heridas. Scrum promueve la predictibilidad creciente. Si no logro ser crecientemente predecible significa que mi trabajo mantiene una complejidad constante. Será hora de revisar entonces si no está cambiando permanentemente alguna de las tres variables que definen la complejidad del trabajo del conocimiento: dominio, tecnología o personas. O las tres a la vez. Las circunstancias fueron complejas y distintas, entendido. Si es así estabilicemos las circunstancias o aprendamos a vivir en la incertidumbre.

Ahora, si las variables no cambian y yo sigo sin mejorar, puedo afirmar sin temor a equivocarme dónde está el problema. Una persona, equipo u organización que no aprende simplemente no está reflexionando sobre su forma de actuar ni mucho menos modifica su comportamiento en consecuencia. La alternativa es simple, pero incómoda. Qué mejor transición hacia un ensayo sobre retrospectivas, ahora que lo pienso.

Retrospectiva ya

En su libro The Art of Making Dances40 la bailarina y coreógrafa Doris Humphrey nos regala esta advertencia: “Nunca dejes el desenlace para el final”. Desde que escuché este consejo por primera vez, allá por el final de los setenta, he comprobado cómo encaja de maravillas en todos los proyectos creativos en los que me he embarcado. Básicamente lo que nos pide Humphrey es que tengamos una noción del todo antes de completar el detalle. Si lo pensamos bien, es una mirada muy ágil del mundo. Si hubiera estado dirigiéndose a un público empresarial, tal vez la recomendación podría haberse reformulado como saber siempre por qué hacemos algo antes de comenzar a hacerlo. O sea, que tengamos una visión clara. En otras palabras, necesitamos preguntarnos: ¿Qué valor buscamos? ¿Qué historia queremos contar?

El desarrollo más tradicional de software solía dejar el desenlace para el final. De ahí la broma de que los equipos están 90% listos el 90% del tiempo, hasta que todo se va al demonio cuando queremos integrar las distintas partes del sistema.

Tomemos la idea de Doris Humphrey y procuremos aplicarla a otro aspecto del desarrollo ágil: las retrospectivas. Una vez reformulada, la frase podría sonar así: “Nunca dejes la retrospectiva para la retrospectiva”.

Muchos agilistas promueven algo conocido como la “directiva básica de las retrospectivas”, formulada originalmente por Norm Kerth41:

Sin importar lo que sea descubierto, entendemos y creemos que todos hicieron lo mejor que pudieron, dado lo que sabían en ese momento, sus habilidades, los recursos disponibles y la situación en la que se encontraban.

Personalmente encuentro la “directiva” algo condescendiente y superficial. Creo que su uso no promueve el tipo de entorno que permite que ocurra el cambio real, significativo. Entendamos de dónde viene todo esto. La directiva fue escrita en una época en la que las retrospectivas eran más conocidas como “postmortems” y ocurrían usualmente al final de los proyectos, que generalmente eran a su vez bastante prolongados. En situaciones como ésas las relaciones estaban ya bastante erosionadas, por decirlo de un modo delicado, por lo que generalmente se respiraba una tremenda propensión a la recriminación. Hacer creer a la gente que todos habían hecho lo mejor que había estado a su alcance (o al menos actuar como si así hubiera sido) podía lograr bajar un poco la temperatura emocional de una reunión de este estilo ¡Por algo se llamaba postmortem!

En los contextos ágiles promovemos la inspección frecuente. Introducir la directiva básica en una retrospectiva ágil parece asumir que no ha habido reflexión en el trayecto que recorrimos hasta aquí. Por más ridículo que suena, esto indicaría que todo comentario, opinión, crítica, duda, preocupación, diferencias y disputas fueron reprimidas, para luego ser reflotadas en una única reunión al final del sprint. Sólo si así fuera vería el sentido de tener una directiva como ésta. Pero veo un paralelismo entre imponer la creencia de que “obviamente somos buena gente” una vez que los hechos ocurrieron y la definición tradicional de testing, en el cual los especialistas de QA tratan de probar la calidad de un software una vez que ya ha sido construido. Ambas estrategias distan de ser óptimas y son profundamente antieconómicas.

Muy por el contrario, si a un equipo se le brinda la posibilidad de reflexionar cada día, lograremos generar un humor radicalmente distinto. En ese caso el equipo evolucionará de modo autogestionado hasta encontrar un modo de trabajo más colaborativo y pleno de confianza, aprendiendo en el camino a afrontar los momentos difíciles con coraje y respeto. Es en esos momentos que podemos ver cómo la calidad de las interacciones y la actitud colaborativa son una parte integral de la estructura de este equipo y no un mero agregado de último momento. Podríamos llamar a esta forma de trabajo desarrollo guiado por la reflexión. Con equipos como estos las retrospectivas no necesitan de ninguna directiva, admonición o regla de conducta.

De hecho, cuando no tenemos la necesidad de destapar la caja de Pandora cada dos o tres semanas, la retrospectiva se convierte en una herramienta mucho más interesante y poderosa. Muchas veces se transforma en un momento de quietud y reflexión, un momento para respirar, un momento para agradecer. Un momento para ser, no para hacer. Esa clase de retrospectivas son las que logran que los miembros del equipo sientan una mayor cercanía entre si, desde un punto de interpersonal. Si logramos este tipo de encuentros, lograremos profundizar el espíritu tribal, la conciencia grupal, ese elemento intangible que poseen los grupos que luchan tras un propósito común.

Buscando encontrar pequeños ajustes, no será necesario pensar en grandes cambios, ya que ocurrirán solos. Y de este modo seguramente ocurrirán también cambios a nivel personal, una evolución tuya como individuo, desde donde emergerá el cambio organizacional más genuino.

Cuando los equipos no logran adaptarse al modelo de retroalimentación continua (y los nuevos equipos tienen muchas dificultades en ese sentido), suelo ofrecer una manera distinta de comenzar una retrospectiva, con el objetivo de entrar al encuentro con la mente puesta en compartir y reflexionar. No es una directiva, ni una declaración a ser proclamada a viva voz, sino simplemente una idea para que cada miembro del equipo la considere en silencio antes de que el diálogo comience. La redacción es una mera sugerencia, no un guión a respetar:

Somos seres emocionales y vulnerables, sujetos a un enorme caudal de influencias provenientes de un sinnúmero de orígenes. A veces nos desempeñamos de maneras magníficas y otras tantas arruinamos todo, pero generalmente nos ubicamos en algún punto intermedio. Durante este último período cada uno hizo lo que hizo y seguramente tuvo sus razones para actuar de esa manera. Aceptemos lo que hay, cómo se dieron las cosas. Y ahora preguntémonos, ¿Qué podemos aprender de nuestras acciones y razonamientos pasados, para así poder guiar del mejor modo posible los que vendrán en el futuro?

Si se alimenta la mirada reflexiva, el proceso de hacer retrospectivas ocurrirá durante todo el trayecto, permitiendo así que el encuentro que se celebra al final del sprint encuentre una mejor razón de ser, que hasta podría estar repleta de amor y celebración.

22 de enero de 2011

Anexo tendencioso: El desafío, como siempre, será el flujo continuo

Siguiendo con la serie de anexos que promueven la adopción cautelosa e informada del trabajo en flujo continuo, voy a apoyar la moción de Tobias de promover la reflexión permanente durante el sprint. Lo que el lector debe comprender es que trabajar (bien) en flujo continuo no es más sencillo, sino mucho más difícil que con iteraciones regidas por un timebox.

Para aquellos equipos que ya dominan la práctica de la reunión diaria y desean pasar a un modelo más fluido de reflexión y adaptación de su proceso de trabajo tengo el siguiente experimento. Además de preguntarse sobre cómo avanza el trabajo sobre el producto, pregúntense también cómo avanza el cambio en el proceso comprometido durante la última retrospectiva y qué dolores han experimentado u observado. Si tienen un tablero físico, pueden utilizar el backlog del sprint para entender el avance de los ítems tanto de producto como de proceso. En cuanto a los dolores, qué mejor que mantener de forma visible, tal vez al lado del tablero principal, un backlog de síntomas. Si alguien desea tomar espontáneamente un ítem de ese backlog, analizar las causas detrás del síntoma y proponer una solución, está más que invitado.

Anexo tendencioso: Siempre habrá montañas más altas

Tobias plantea en este ensayo una máxima del universo scrum que no comparto en su totalidad. Supuestamente un simple encadenamiento de pequeños cambios incrementales en la forma de trabajo nos evitará eventuales terremotos en el proceso. Kaizen, el cambio continuo, pequeño, es la gota que perfora muchas piedras. Eso sí, creo firmemente que a veces no quedará otra que usar la maza.

Kaikaku, el cambio drástico, innovador, tiene sus riesgos, pero a veces es la única manera de escapar de un máximo local. No estoy seguro de que sea posible cambiar de manera paulatina la manera en la que se calculan los bonos en una organización. Tal vez sirva pensar que todo kaizen no es ni más ni menos que un paso hacia un kaikaku que vendrá. Hacer scrum es entender que la perfección existe, es inalcanzable, pero eso en vez de desmotivarme me empuja a experimentar cada día, a cada hora. Siempre se puede estar más cerca, nunca se llega. Scrum es imposible, es una utopía útil. No lo sufran, hay mucho para disfrutar en el camino.

El alma de scrum

Scrum nació y creció con un contexto muy concreto en mente: equipos pequeños que comparten un espacio físico de trabajo y que son capaces de entregar software funcionando rápidamente. Scrum es simple, elegante y ha demostrado que entrega buenos resultados bajo este tipo de configuraciones. Lamentablemente demasiados empresarios y altos gerentes han entendido que el framework es un elíxir infalible y han intentado utilizarlo sin adaptación alguna en organizaciones enormes y pesadas, profundamente infectadas por la necesidad de control y con equipos desparramados a lo largo del mapamundi. Algunos hasta han pretendido scrum que funcione sin el más mínimo ajuste en entornos fuera del software. Recuerdo algunos de estos casos y resuena en mis oídos el sordo ruido de martillazos estériles tratando de hacer encajar un madero cuadrado en un agujero redondo. Creo fervientemente que forzar el uso de scrum causa más desolación que soluciones.

No quiero decir con esto que los principios subyacentes a scrum no tengan un amplísimo espectro de posibles aplicaciones, porque de hecho sí lo tienen. El problema de fondo es que mucho entusiastas de scrum no terminan de comprender estos principios o por qué son importantes. Muchos gerentes, consultores, coaches y scrum masters se enfocan únicamente en sistemas, procesos y prácticas. Peor incluso, tratan de mezclar sin más “scrum” con sus actuales patrones de trabajo, que a menudo se encuentran en la orilla opuesta, creando una quimera surrealista y aterradora, que de poco termina sirviendo en el día a día.

Usar scrum como parche es la fórmula perfecta para el fracaso, sea cual sea la circunstancia. La realidad lo demuestra una y otra vez. La obediencia por la obediencia en si de cualquier procedimiento o sistema prescripto siempre causa algún tipo de daño. La gente deja de pensar por si misma, deja de innovar y termina frustrada, indignada y reticente cuando las cosas no terminan saliendo como estaban planificadas. Scrum es la nueva receta, el nuevo plan, la nueva marca, y esa su tragedia.

En vez de intentar utilizar scrum como una bala de plata, recomiendo tratarlo como una clase abstracta, un ideal platónico. Dentro de cualquier implementación efectiva de scrum vivirá un conjunto de principios, que una vez abstraídos podrán ser utilizados en una enorme diversidad de situaciones, con el objetivo de gestar entornos que generen compromiso, creatividad y valor concreto. He aquí cómo entiendo yo el alma de scrum:

Los principios de scrum

Foco

El principal de los principios. Cuando Jeff Sutherland creó scrum en 1993 mientras trabajaba para Easel Corp42, observó la disfunción con la que muchos nos enfrentamos hoy en día con mucha claridad. Frente a él había una cultura de escasez: nunca alcanzaban ni el tiempo, ni la gente, ni los recursos ni el dinero. Casi todo el trabajo tenía prioridad alta, lo que obviamente daba como resultado que nada terminaba siendo realmente prioritario. Sutherland se percató de que si el equipo podía trabajar en sólo una cosa a la vez, ese objeto (producto/proyecto/funcionalidad) tendría a su disposición todo el tiempo, la gente, los recursos y el dinero que necesitaba. Sería factible concluir ese trabajo, liberando así de esa gran preocupación a los miembros del equipo, para así poder enfocarse en algo fundamental: el siguiente ítem de la lista. Al utilizar el poder del foco, la organización pasó de una cultura de escasez a una de abundancia. Enfocarse en una sola cosa a la vez es algo tremendamente simple, tremendamente obvio y encima funciona.

Alineamiento

Para poder cumplir con las necesidades del negocio y los usuarios, los equipos de desarrollo deben lograr involucrar con frecuencia a todos los interesados. Considero que una buena parte del sufrimiento por el que hemos pasado en el mundo del desarrollo de software se debe a una falta de alineamiento entre las partes. Los requerimientos se malentienden o se transmiten con descuido e inexactitud. Aquello que los clientes y usuarios piden no termina siendo lo que en realidad necesitan, se toman decisiones basadas en supuestos a todos los niveles y los largos ciclos de desarrollo hacen que los errores no salgan a la luz hasta que el costo de adaptarse es insostenible. Los equipos correctamente alineados se reúnen frecuentemente con todos los interesados: planifican al comienzo de la iteración, reflexionan al final y verifican conjeturas, ideas y supuestos de manera constante durante el ciclo de desarrollo. Las conversaciones de alineamiento deben realizarse en un marco de absoluta colaboración, dentro del cual cada participante respeta profundamente tanto el conocimiento como la experiencia de los otros.

Artful Making43

Este concepto fue introducido por Lee Devin y Rob Austin en su libro Artful Making44. Devin, un director de teatro, y Austin, un profesor de negocios, proponen que para que un equipo tenga éxito en un espacio donde se necesita improvisación y creatividad (como el del desarrollo de software) se requieren cuatro cualidades, a las que bautizaron release, colaboración, ensemble y juego. En otras palabras un equipo requiere cierta libertad para que sus miembros puedan interactuar, generando un entorno colaborativo, que permitirá lograr una sensación de ensemble, en el cual equipo y creación son más grandes e interesantes que la suma de sus partes. Para que esto ocurra será necesario fomentar un espíritu lúdico, que permitirá a su vez que se tomen riesgos, abrazando al error como una oportunidad de aprendizaje ¡El objetivo será que el equipo aprenda a tomarse el producto o el objetivo de negocio en serio, más que a si mismos!

Autoorganización

Los grupos humanos son por naturaleza sistemas adaptativos complejos y, por ende, se autoorganizan. Tratamos infructuosamente de imponer control y dirección sobre los individuos a través de técnicas de gestión como la asignación, el reporte de estado (diario o semanal) y otros mecanismos que sólo sirven para malgastar tiempo y fabricar individuos tan obedientes como irritados y rebeldes. La autoorganización se basa en la sencilla idea de que la gente que está más cerca del problema es la más indicada para resolverlo. En software eso significa que los desarrolladores son los más indicados para decidir cómo se programa, siempre considerando que existe un diálogo provechoso que permita comprender los requerimientos y su criterio de aceptación. La autoorganización no implica anarquía ni caos, sino libertad para innovar. Requiere la participación activa de todas las partes, de clientes a gerentes, pasando obviamente por los propios trabajadores. Entre todos ellos deberán fijar objetivos y límites claros, que permitirán que el equipo desarrolle soluciones adecuadas, utilizando las mejores herramientas a las que tenga acceso. La autoorganización comienza con el release y se alimenta de las otras tres cualidades del artful making.

Ritmo

Sin límites temporales ni conversaciones frecuentes de alineamiento, todo lo descrito arriba se convierte en algo soso y endeble. El ritmo es el andamiaje que sostiene todo esto y permite a las organizaciones avanzar velozmente (sin apurarse ni entrar en pánico), destapando equivocaciones y errores de juicio en pocas horas o días, en vez de en semanas o meses...¡O incluso al final de todo el proyecto! Scrum introduce la idea del timebox, por medio del cual se llega a un acuerdo antes de comenzar, cuyo resultado será que el producto generado y el proceso con el que se trabajó se revisarán al finalizar el período. Los timeboxes de scrum suelen durar entre una y tres semanas. Todas las conversaciones de alineamiento deben tener días y horarios ya fijados, de modo tal que todos puedan tener su agenda libre de antemano y poder llegar preparados al encuentro. Los integrantes del equipo también deben encontrarse de forma diaria para lograr alineamiento interno. Disponer de un latido regular en forma de sprint también permite un alivio entre cada uno de ellos; un momento para respirar, pensar y explorar nuevas ideas. El ritmo en definitiva lleva al flujo. La idea de que trabajar de forma continua traerá instantáneamente la posibilidad de lograr flujo está sencillamente errada. Lo que traerá sin dudas es un simple amontonamiento de tareas.

Scrum en si se basa en cinco principios: alineamiento más ritmo nos dan proceso empírico; el foco nos permite manejar el backlog y, sumado al alineamiento, permite lograr compromisos sensatos; artful making y la autoorganización logran crear el ambiente adecuado para que exista un equipo que produce soluciones de excelencia a problemas muy complejos. Utilizar estos principios conscientemente será de ayuda para que cualquier organización, sea grande o pequeña, local o distribuida, de software o de cualquier otra disciplina, pueda generar una forma de trabajo que esté enteramente alineada con scrum, sin necesariamente ser scrum propiamente dicho.

El framework de scrum es un esqueleto, al que damos carne y hueso por medio de proceso y prácticas. Esto está bien, siempre y cuando estemos pendientes del contexto que nos rodea. Cualquiera sea el caso, sin su alma a cuestas, scrum puede convertirse en un autómata, controlado por (y a merced de) fuerzas externas. De ese modo jamás será ni verdaderamente emergente ni genuinamente libre.

15 de febrero de 2012

Anexo tendencioso: Sí y además

Este ensayo presenta una generalización impecable y necesaria de scrum, a la que apenas quisiera agregar tres elementos, poco mencionados en la literatura, que considero parte fundamental de la esencia del framework:

Crecimiento orgánico

Algunos lo han llamado desarrollo iterativo incremental. En las reglas de scrum se describe como software funcionando. Personalmente encuentro muchísimo más poderosa la analogía del organismo vivo. Su crecimiento es holístico (casi ningún árbol desarrolla enormes raíces antes de tener tronco, ramas y hojas), sostenible (los árboles que viven largo tiempo no se secan ni pudren en su interior, como sí le sucede al software que no refactorizamos ni testeamos) e increíblemente adaptable. Al fin y al cabo ágil implica que hemos logrado minimizar el costo del cambio, al que consideramos inherente.

Utopía útil

Scrum es imposible y eso es bueno. Idealismo a la oriental. La perfección existe, es inalcanzable, pero todos los días voy a hacer algo para alcanzarla. El equilibrio inestable, el eterno balance entre kaizen (cambio pequeño y paulatino) y kaikaku (cambio disruptivo ocasional), la búsqueda incesante es el palpitar de ese organismo que crece por instinto y pasión. La retrospectiva y el scrum master son el momento y el embajador de una filosofía distinta.

Humildad intelectual

¿Por qué decidimos hacer scrum al fin y al cabo? Porque sabemos que nos vamos a equivocar. Así de simple, así de intolerable. Si el error es ineludible, decidimos convertirlo en una inversión y abrazar el empirismo. En el mundo de la complejidad, el pensamiento sigue a la acción. He aquí el cambio de paradigma.

Cultura:
La tierra prometida

Para prosperar en el mundo de los negocios de hoy en día precisamos la velocidad de la mente humana para poder adelantarnos a nuestro torpe andar; necesitamos la inmediatez del contacto visual y físico (imaginemos que nos abrazamos, compañero de aventura) y necesitamos la creatividad propia del espíritu colaborativo, desencadenada por medio de la confianza, la autoorganización, inundados de asombro y tensión. Solo así, tal vez, en una de esas, tendremos alguna chance.

Cambio organizacional catastrófico

La intuición me dice que podemos llegar a destinos bien interesantes si exploramos detenidamente el término “cambio organizacional catastrófico”, una frase acuñada por Michael Ivey para describir el cambio de paradigma que requiere una organización para realmente entregarse a la agilidad45. Muchos se han opuesto a la idea, respondiendo a mi entender de un modo algo reaccionario, incluso temeroso. Leer estas opiniones me hizo frenar para repensar qué tendrá el concepto para resultar tan terrorífico. El resultado de esa reflexión lo pueden leer en este ensayo.

El cambio organizacional catastrófico es un término interesante y de gran riqueza, de ribetes poderosamente anárquicos, pero al mismo tiempo dotado de un tinte compasivo. Los nuevos paradigmas necesitan un nuevo lenguaje, por lo que no me desalientan las connotaciones negativas de la palabra “catástrofe”. Al fin y al cabo, hasta que Jeff Sutherland no adoptó el término para describir un proceso de desarrollo de software, la palabra “scrum” pertenecía al mundo del rugby y significaba “aglomeración alborotada de personas”46. El lenguaje puede cambiar para adaptarse a las necesidades de quien lo utiliza. Es increíblemente flexible. Por suerte.

Cambio organizacional catastrófico es una frase nueva, pero dista de ser un concepto novedoso. El cambio catastrófico tiene lugar cuando descubrimos nuestra propia verdad al llevar nuestras zonas de confort y las de otros al límite, tomar riesgos, aceptar el error y atravesar sin dudar nuestros mayores miedos. Éste y no otro es el cambio verdadero, real, palpable. Allí y no en otro lado está el progreso. No creo ni un poco que emplazar una metodología-marca, como ser scrum o XP, en una empresa estropeada logre resolver ninguno de sus conflictos más profundos, sino que será un parche más. Seguramente sea de mejor calidad que sus antecesores, pero no olvidemos que sigue existiendo un inabarcable abismo entre el síntoma y la enfermedad que resiste bajo la superficie.

Recuerdo haber escuchado un conmovedor comentario de Jon Spence durante el Scrum Gathering de 2005: “El éxito es nuestro enemigo”. El peligro más profundo vive en el éxito rápido y vistoso, pero cuyos efectos se notarán solamente a corto plazo. Esos son los éxitos que nos van a hacer creer que realmente estamos avanzando, cuando en los hechos lo único que estamos haciendo es poner una nueva capa de pintura sobre una fachada que se cae a pedazos. Las estrategias superficiales de este estilo no son sostenibles en el tiempo ¿Puede scrum por si solo tener éxito? Lo dudo, aunque tal vez antes deberíamos definir qué entendemos por “éxito” y, ya que estamos, también “scrum”, ¿no?

Desarrollar buen software y entregar valor al cliente a tiempo son, sin duda, nobles objetivos, pero realización personal, maestría, excelencia...hacia ahí quiero ir, sí señor ¿Cómo encaja este cambio de paradigma hacia lo ágil con, digamos, todo lo demás? ¿Cómo podemos modificar el equilibrio de poder, no pasándolo de una persona o grupo a otro, sino en términos más redistributivos? ¿Cómo podremos socavar hasta el derrumbe al statu quo introduciendo maneras de hacer las cosas que ninguno de nosotros ha siquiera concebido aun? ¿Podemos? ¿Debemos? Grandes interrogantes que, sin duda, debemos plantear en voz alta de tanto en tanto.

Hay muchas estrategias de cambio organizacional basadas en la jerarquía y el autoritarismo que suelen terminar en catástrofe. El problema es que no redundan en un cambio auténtico ni significativo. Es eso justamente lo que los críticos del cambio organizacional catastrófico parecen no entender. El foco está puesto en el cambio, un cambio profundo y real, no en la catástrofe. La catástrofe es el trayecto, no el destino. Las armas del cambio catastrófico no son la maza ni la topadora, sino más bien aquellas del artesano, delicadas y precisas, utilizadas con paciencia y amor.

El cambio más esencial no sucede de arriba hacia abajo en una organización. Hay demasiado en juego para los participantes, demasiado que perder si las cosas no salen como las habían planeado. El cambio se produce desde dentro (pregúntenle a un terapeuta si no) y si hablamos de organizaciones, eso significa que la transformación ocurrirá de abajo hacia arriba. Es hora de sacarnos de la cabeza a los sponsors ejecutivos y empezar a buscar sponsors en los programadores novatos, en las secretarias, en los pasantes, en aquellos que no tienen ni un ápice de poder. Sembremos los niveles más bajos de las organizaciones con agentes de pasión: eduquemos, nutramos, dejemos el conocimiento al alcance de la mano, charlemos con ellos, compartamos historias, riámonos juntos, agitemos sus mentes y hagámosle preguntas incómodas. No temamos. El cambio será más lento de lo que pensábamos, pero será auténtico y, aceptémoslo, puede que incluso sea catastrófico.

El terremoto de 1904 en San Francisco no ocurrió de la noche a la mañana. En verdad tomó años de ínfimos y sutiles desplazamientos en los estratos rocosos para que un día los cimientos de la ciudad se desplomen: cambio catastrófico. La Revolución Francesa no fue producto de un capricho. Distintos grupos de personas, pequeños y medianos, fueron cambiando paulatinamente su mirada del mundo y por ende la de aquellos que los rodeaban. Fue así como la ola creció, hasta que finalmente explotó por los aires: cambio catastrófico. Las termitas devoran edificios, pero desde dentro. La destrucción se mantiene invisible, hasta que es demasiado tarde: cambio catastrófico. En todos esos casos podemos elegir entre lamentar la catástrofe y abrazar el cambio.

El cambio catastrófico comienza con el individuo. Más específicamente, empieza con el individuo en el contexto de su grupo, la organización a la que pertenece y la sociedad en la que ésta existe. Desconozco exactamente dónde debemos poner el foco para dar inicio a ese cambio, pero tengo planeado explorar las distintas alternativas y aprender sobre ellas en la medida que me sea posible. Solo estoy seguro de una cosa: el cambio debe extenderse más allá del mundo de la tecnología y la ciencia, alcanzando incluso el mundo del arte.

Hoy en día, entre otras cosas, brindo consultoría de tiempo parcial a una compañía que desarrolla productos de software en Silicon Valley. El foco de mi trabajo está puesto en introducir técnicas de desarrollo iterativo e incremental. No mencioné ninguna catástrofe el día que llegué, sino que simplemente actúo sobre el día a día. Pero incluso trabajando con pequeñas metas siento que es importante ser genuino y decir lo que pienso realmente, todo aquello que agita mi corazón. La agilidad no es un conjunto de prácticas, sino más bien una forma de vida. Creo y confío fervientemente en eso.

5 de diciembre de 2005

Anexo tendencioso: La madre de todos los kaikakus

Kaizen no basta, ya lo dijimos. Lo que no dijimos es hasta dónde deberían llegar los kaikakus. Tobias lo deja claro: hasta el fondo de la cuestión. Considero esencial retomar un concepto de este ensayo sobre el que poco he escuchado en el mundo ágil. La palabra mágica es redistribución. No conozco sponsor que no le tema o rehúya.

De lo que hablamos cuando hablamos de horizontalidad es de poder. Repartir el poder, las decisiones, entre toda la organización. Democratizar, en mayor o menor medida. Sobre eso se habla y se deberá seguir hablando. El debate pendiente es el de la propiedad. Hoy en día decidimos la propiedad de manera predictiva. Nos asociamos, decidimos participaciones y luego empezamos a trabajar. Tal vez la única propiedad que cambia de manos día a día sea la de las empresas que cotizan en bolsa. Lo que queremos es algo parecido, pero en función del valor agregado. Si alguien ha hecho fantásticamente su trabajo, ¿no debería ser un poco propietario de aquello que ayudó a crear?

La cooperativa líquida es una idea rara con la que vengo fantaseando últimamente. Todos los meses cada uno de sus integrantes tiene 100 acciones para repartir entre sus pares. Todas deben ser entregadas, siempre a los otros, según su mérito, de forma abierta y con feedback. Cuando haya ganancias, las repartiremos en base a las acciones. Si alguien deja la cooperativa, sus acciones se diluyen lentamente. Si hay que tomar decisiones complejas, los integrantes tienen tantos votos como acciones. Prometo experimentar. Palabra de agilista.

Anarquía ágil

La anarquía es un concepto al que muchos rehuimos en el mundo corporativo. Pensamos que no tiene sitio en un mundo de disciplina, control y balances. Y sin embargo cada vez más organizaciones eligen el camino de la agilidad. Interesante conflicto.

La agilidad es una forma compasiva de anarquía. Deja atrás, de forma moderada y con suavidad, las estructuras jerárquicas y controladoras para dejar paso a alternativas más colaborativas y basadas en la autogestión. El anarquista compasivo exige que sus semejantes estén siempre en pie de igualdad, estimula las soluciones emergentes, deposita el poder en el individuo en la medida que sea posible y busca evitar como sea todo proceso que implique una deshumanización y marginación del trabajador. Los paralelismos con la agilidad se ven claramente. Tanto el anarquista como el agilista creen que el cambio auténtico no surge de la obediencia y la coerción, no puede jamás provenir desde arriba, sino que comienza en las bases, al nivel del individuo. Cada uno de nosotros es en parte responsable por el cambio. Así debe comenzar la revolución.

He seleccionado cuidadosamente un conjunto de citas que entiendo logra describir esta perspectiva de la anarquía.

Si bien la definición más difundida del anarquismo lo describe como un movimiento violento, opuesto a la existencia de un Estado, al anarquismo lo describe en verdad una tradición mucho más sutil y matizada que aquella definida a partir de una simple oposición al poder gubernamental. Los anarquistas se oponen a la idea de que el poder y la dominación son necesarios para la sociedad y en cambio abogan por formas de organización social, política y económica más cooperativas y contrarias a todo tipo de jerarquías.

—L. Susan Brown47

Anarquismo, para mi, significa no solo la negación de la autoridad, no solo una nueva economía, sino una revisión de los principios de la moralidad. Significa el desarrollo del individuo, así como también la afirmación del individuo. Significa responsabilidad por uno mismo y no la veneración del líder.

—Voltairine de Cleyre48

La gente se olvida que la industria no es un fin en si mismo, sino que debería ser solo un medio que permita al hombre asegurar su subsistencia material y lograr que le sean accesibles las bendiciones de una cultura intelectual más elevada. Cuando la industria es todo y el hombre no es nada comienza el terreno del despiadado despotismo económico, cuyo funcionamiento no es menos desastroso que el de cualquier despotismo político.

—Rudolf Rocker49

El anarquismo es una filosofía de libertad. Es un corpus de ideas revolucionarias que reconcilia, como no lo hace ningún otro concepto revolucionario, la necesidad de libertad individual con las demandas de la sociedad. Es una filosofía que comienza por el individuo y trabaja de forma ascendente, en vez de comenzar por el Estado y luego descender. La estructura social en una sociedad anarquista se reduciría cuidadosa y conscientemente al mínimo posible y sería meramente funcional; donde hiciera falta organización, se mantendría, pero no habría organización por la organización misma. Esto ayudaría a evitar que las organizaciones se petrifiquen hasta transformarse en instituciones, el núcleo duro de la institución gubernamental.

—Bill Christopher, Jack Robinson, Philip Sansom y Peter Turner50

Es la compasión es lo que impide que la anarquía se degenere en caos violento así como también previene que la autonomía individual se convierta en insolencia e indiferencia por los otros. La anarquía es lo que impide que nuestra compasión se convierta en una carcaza vacía de cualquier autenticidad—es lo que impide que nuestro amor por los otros se convierta en una mercancía que se nos vuelve a vender o en un ardid para lograr nuestro consentimiento para con los dictados de la autoridad. La anarquía compasiva se trata de encontrar y apreciar ese alma genuina que existe en los seres humanos, manteniéndola libre de toda autoridad, sumisión, moralismo y roles estáticos.

—anarchopedia.org

Soy un anarquista no porque crea que el anarquismo es el destino final, sino porque no existe tal cosa como un destino final.

—Rudolf Rocker51

Hay infinidad de buenas ideas en el mundo. Muchas de ellas se encuentran al acecho, latentes, listas para ser absorbidas mientras se pasean por los recovecos de la contracultura. Uno de los grandes aportes que la agilidad le ofrece al mundo corporativo es la libertad para explorar fuera de los confines de aquello que se considera correcto y apropiado, para incluso terminar abrazando ideas que solamente una década atrás habrían sido consideradas anatema en las grandes corporaciones. Varios pioneros de la agilidad mencionan la valentía como un valor clave de esta forma de trabajo. Indudablemente hace falta coraje para traspasar más allá de los límites dentro de los cuales nos sentimos seguros, para escuchar buenas ideas otrora consideradas despreciables o peligrosas. A la larga, lo más prudente (y tal vez cuerdo) es avanzar confiado, tomando más de un riesgo en el camino.

10 de junio de 2009

Anexo tendencioso: Adiós al prejuicio

Lo reconozco, la palabra anarquismo me producía rechazo antes de leer este ensayo. La asociaba a cócteles Molotov, caos en espiral, falta de cohesión, egoísmo y violencia gratuita. Gracias, simplemente gracias por abrir mi mente y mi corazón. Scrum como puerta de entrada a un mundo de ideas nuevo, intrigante, desafiante. Qué va, nadie puede decir que todo esto no es verdaderamente emocionante.

Cabalgando dinosaurios

Redacté este ensayo a modo de respuesta tras haberme enterado que el CEO del Project Managment Intitute (PMI) había sido invitado como primer orador a una conferencia de la Scrum Alliance, una organización a la que pertenecí hace tiempo, para la que trabajé y con la cual me ilusioné, creyendo que simbolizaba el futuro de scrum. Que hoy en día no me encuentre afiliado de manera alguna con esa institución no debería representar conflicto alguno con los sentimientos aquí expresados.

El Project Management Institute (PMI) es una enorme y poderosa organización que lleva tiempo promoviendo principios de management tayloristas52, de formas más o menos explícitas. Muchos respetan y hasta veneran a esta organización, pero yo personalmente no logro evitar verla como opresiva. Tal vez lo mejor sea poner esta opinión en contexto. El Scrum Gathering de Orlando se acerca y Gregory Balestrero, el director ejecutivo del PMI ha sido invitado, con gran fanfarria, a ser uno de los principales oradores del evento. Quisiera objetar esta decisión. No es que tenga algo contra él (de hecho no había escuchado jamás su nombre hasta este momento), sino que me hace sentir bien incómodo la sola idea de que la Scrum Alliance se dirige al PMI para aprender sobre...¿qué, exactamente? No lo sé. Luego de intentarlo durante tres largos años, no he logrado encontrar una sola razón para escuchar aquello que el PMI tenga para decir. Creo que no es fácil declamar algo así sin herir las sensibilidades de más de un integrante de la comunidad de practicantes de scrum.

Invitar a alguien como orador implica que esa persona tiene algo importante para decir, algo que necesitamos oír. Balestrero, el hombre, puede que sí tenga algo importante para decir, pero Balestrero el CEO del PMI seguro que no. El PMI es una organización obsoleta, que representa y promueve una forma de trabajo que, se sabe hoy en día, posee enormes deficiencias cuando se la utiliza para guiar el desarrollo de software. Que el PMI quiera cambiar es una buena noticia, que el PMI tenga algo importante para contarle a quienes hacen scrum ya suena menos probable.

Si el señor Balestrero está interesado en aprender scrum, entonces invitémoslo al Scrum Gathering para que participe como uno más. Le doy la bienvenida, como se la doy a cualquier otro que quiera aprender sobre scrum. No tengo razón alguna para pensar que el señor Balestrero no es una persona íntegra que desea incorporar nuevos conocimientos. Considerando el lugar que ocupa hoy en día, no tengo dudas que debe ser una persona muy inteligente y apasionada. Ese nivel de pasión y determinación siempre es bienvenido en el mundo de scrum. En fin, preferiría que asista a la conferencia simplemente como Gregory, no como “el gran embajador del PMI para la búsqueda de nuevos horizontes en la gestión de proyectos”, como lo describe públicamente el material que distribuyó la Scrum Alliance. No tengo ningún interés en escuchar “un impactante mensaje sobre la importancia de la gestión de proyectos para alcanzar el éxito en el complejo entorno global de los negocios de hoy en día”. La retórica corporativa es tediosa y descreo de ella.

Scrum, como lo entiendo y vivo día a día, nada tiene que ver con la gestión de proyectos. Personalmente evito utilizar el término ”gerente de proyectos ágil”, al que considero un oxímoron caminante. Ken Schwaber dice a menudo que no existe el rol de gerente de proyecto en scrum. Si no lo hay, ¿entonces qué sentido tiene hacer equipo con el Project Management Institute? Huele a conservación del statu quo, tratando de apaciguar el eventual nerviosismo de una organización muy poderosa, cuya supremacía se ve amenazada. Yo personalmente desconfío de esta iniciativa.

Siempre vi al movimiento ágil como una revolución en el mundo del software, mediante la cual lograríamos sacarnos de encima el peso de la opresión, liberándonos con el objetivo de definir nuevas y mejores formas de ser y trabajar. La tragedia de muchas revoluciones es que, una vez que triunfan, los líderes comienzan a comportarse como aquellos que causaron que se requiera una revolución originalmente. Los oprimidos se convierten en opresores, adoptando esencialmente los mismos rasgos de aquellos que depusieron, básicamente porque no se les ocurre ninguna manera alternativa.53

George Orwell caracterizó de manera brillante este fenómeno en la novela Rebelión en la Granja, una alegoría de la Revolución Rusa y los eventos que le siguieron. Hacia el final del libro, Napoleón, cerdo y líder de la revolución, ya camina con dos patas, se viste con ropas humanas y vende a sus mejores amigos para poder comer carne de caballo.54

¿Por qué querrá la Scrum Alliance trabajar codo a codo con un dinosaurio como el PMI, en un mundo tan cambiante, tan ágil y en continua evolución? No tengo dudas que sería un paso atrás. Quisiera ser claro con esto: veo un gran valor en trabajar con aquellos miembros del PMI a los que les interesa scrum, pero no veo ningún valor en trabajar con la organización en sí. Si bien es cierto que tiene algún grado de influencia hoy, esa influencia está en pleno declive producto de la agilidad. Al fin y al cabo sus enseñanzas nunca fueron demasiado útiles para el mundo del software. Yo digo que los dejemos ser y, eventualmente, morir. Busquemos todos juntos, los individuos, formas completamente novedosas de colaborar y mejorar nuestras profesiones y habilidades. Las instituciones gigantes y monolíticas que procuran representar “los intereses” de sus miembros no encajan con este siglo. Tal vez lo pequeño funcione mejor. Honestamente espero que la Scrum Alliance no crezca hasta llegar a convertirse en un PMI. (A la fecha de publicación, esta esperanza no se ha cumplido. La Scrum Alliance tiene hoy más un cuarto de millón de miembros activos, un consejo directivo con varios miembros que no han sido elegidos democráticamente y siete certificaciones en curso). En su lugar me encantaría ver como se esparce en pequeños y apasionados grupos auto-gestionados, cada uno con sus propias prioridades e intereses.

Percibo una opresión no sólo ejercida por el PMI, sino más bien por los monolitos corporativos en general; son por definición increíblemente pesados y estancos. Me pone muy incómodo la cada vez más íntima relación entre el PMI y la comunidad de scrum. Creo que deberíamos estar más enfocados en nuestros objetivos de transformación, mantenernos firmes en la causa y no descarrilar víctimas de ilusiones de grandeza. Cuatro patas está muy bien. Punto final.

11 de marzo de 2009

Anexo tendencioso: De cerdos opresores y otras tentaciones

Si bien no prosperó en definitiva el coqueteo ocurrido en 2009 entre el PMI y la Scrum Alliance , queda flotando aún en el aire la cuestión de la identidad de esta última. Como miembro activo y otorgador de certificaciones me encuentro en una posición extraña, íntima y potencialmente reflexiva y autocrítica. Para clarificar a lo que me refiero por opresión quisiera parafrasear a Boal: “existirá opresión siempre que haya monólogo donde debería haber habido diálogo”.

Definición en mano, quisiera debatir en voz alta si la Scrum Alliance ha decidido convertirse en un cerdo bípedo que no para de monologar. Hemos sido, lo admito, un poco sordos o tozudos. El curso Certified ScrumMaster sigue siendo un fantástico Caballo de Troya en potencia que degenera demasiado seguido en mercancía negociable. Tal vez más por inacción e impotencia que por complicidad explícita hemos apenas rasguñado el objetivo de transformar el mundo del trabajo, tal como predicamos en nuestra visión.

Como miembro activo, como parte integrante de la Scrum Alliance, como engranaje de su maquinaria, me comprometo ante usted, lector atento y crítico, a trabajar intensamente para que la lanza no solo esté afilada, sino que apunte hacia el opulento opresor y no hacia el vapuleado oprimido. Deséenme suerte, disciplina y tozudez.

Opresión corporativa

Opresión: Carga impuesta de manera injustificable sobre algún individuo o grupo, que se lleva a cabo luego de interferir con su poder, intereses u oportunidades. La opresión puede ser intencionada o resultado involuntario de una cierta disposición social; puede ser reconocida como tal, o puede resultar inadvertida por aquellos que están siendo oprimidos.

The Oxford Dictionary of Philosophy

Solemos visualizar la opresión sólo cuando es explícita, por ejemplo en aquellas situaciones en la que se utiliza como arma para sojuzgar a los derrotados o para apaciguar cualquier tipo de agitación o deseo de revuelta entre las clases más bajas; pero la opresión existe de muchas maneras distintas y no solo afecta a los más pobres y marginados. Podemos descubrir varios niveles de opresión en las grandes organizaciones hoy en día, ejercida con gran brutalidad, discreción y delicadeza sobre profesionales de clase media, que disfrutan de excelente paga y beneficios envidiables.

Tomemos como ejemplo la cultura del cubículo, tan arraigada en nuestras mentes como la manera correcta en la que se trabaja en el mundo del software, incluso luego de más de diez años de agilidad. Aislar a alguien en un cubículo es un acto controlador, que tiene como objetivo lograr obediencia y encuadramiento. Las cárceles en el mundo entero apelan al concepto del confinamiento en soledad como forma de castigo—hasta se podría hablar de un castigo que limita con lo cruel e inusual: así de antinatural nos resulta a las personas estar alejadas de nuestros pares. No hay que desafiar los límites de la imaginación para encontrar las similitudes entre el cubículo corporativo y la celda unipersonal. Sin el apoyo de sus pares, un individuo es mucho más vulnerable a la sugestión y estará más dispuesto a acatar cualquier instrucción ¿Será esa la intención explícita cuando se arma una granja de cubículos? Seguramente no, pero el resultado sigue siendo el mismo.

La opresión va mucho más allá de la distribución física en las oficinas. Día a día se suceden crueles juegos de poder, casi siempre con gran fervor por parte de aquellos que habitan las más altas cúpulas, pero con un entusiasmo que declina rápidamente cuando nos acercamos a las bases de la organización. La opresión aquí es deliberada en algunos casos, pero suele ser el “resultado involuntario de una cierta disposición social”, que se manifiesta en la tan mentada frase “así son las cosas aquí”.

Este tipo de opresión suele ocultarse tras las buenas formas corporativas, tapada por lo que se conoce como normas socialmente aceptadas. Su cara más pérfida se deja ver si quitamos la máscara que representan expresiones como “diversión”, “trabajo en equipo” o “espíritu comunitario”. Entre las víctimas esta opresión se deja ver en forma de un acatamiento sigiloso, un enorme miedo a cometer errores y una sensación generalizada de que es mejor no tomar una decisión que tomar una que sea juzgada como incorrecta. Es preferible posponer que actuar. El resultado de una cultura organizacional opresiva es la inercia, la parálisis total. El problema es que si a esta opresión no se la llama por su nombre no hay forma de poder entenderla y tratarla. Una organización sojuzgada por la opresión no podrá jamás ser verdaderamente ágil, por más ornamentos novedosos y supuestamente eficientes que utilicemos como fachada.

Por sobre la opresión existente al nivel de organización es posible vislumbrar una cultura del miedo entre compañías, una cultura de cumplimiento de “estándares” (ej. ISO 9001 o CMMi). He presenciado en dos ocasiones el enorme e innecesario esfuerzo que debían hacer aquellos que debían modificar su comportamiento habitual para poder cumplir con las nuevas reglas y en ambos casos tuve delante de mis ojos una imagen patética: trabajadores temerosos, aterrados por la sola idea de cometer una equivocación, aparentemente exhaustos, pero interiormente muertos de miedo. Tal vez otros han pasado por una experiencia distinta, pero no exagero, esa fue mi vivencia.

¿Pero quién es en definitiva responsable del statu quo? ¿Los opresores? ¿La sociedad? Sería fácil asignar responsabilidades y seguir con nuestra vida. La realidad, desde mi punto de vista, es que el oprimido es el verdadero culpable. En una sociedad democrática tenemos la posibilidad de elegir. Si estamos oprimidos (¡Y vaya que lo estamos!) es porque elegimos vivir así.

No podrá jamás existir ningún sistema generalizado de opresión...sin el consentimiento del oprimido.

Florynce Kennedy55

La solución obvia parecería tener dos simples pasos: a) reconocer el problema b) actuar distinto. Lamentablemente la realidad es un poco más complicada. Con demasiada frecuencia los oprimidos no desean el cambio; simplemente quieren quedarse donde están. Esta es la desagradable realidad con la que debemos convivir. Todos hemos visto individuos que ascienden a un mando medio y cambian su conducta de forma consecuente, encajando perfectamente con el sistema y emulando a sus superiores. Todos hemos visto equipos que terminaron cayéndose a pedazos como consecuencia de luchas intestinas. De hecho una parte clave de cualquier buen curso para convertirse en scrum master debería enfocarse en lidiar con situaciones como esa. Los sistemas de premios y castigos en la mayoría de las corporaciones que desarrollan software están basados en la superioridad individual. Claro está, para que alguien sea superior otros deben convertirse en inferiores.

El filósofo y teórico en educación Paulo Freire comenta de este modo en su libro Pedagogía del Oprimido sobre el síndrome de las peleas internas entre nativos oprimidos en países colonizados: “Dado que el opresor existe aun dentro de sus camaradas oprimidos, cuando los atacan están indirectamente atacando también a sus opresores”.

Freire continúa explicando que “por otro lado existe, en cierto momento de la experiencia existencial de los oprimidos, una atracción irresistible por el opresor. Por sus patrones de vida. Participar de estos patrones constituye una aspiración incontenible. En su enajenación quieren, a toda costa, parecerse al opresor, imitarlo, seguirlo”.

Si los enormes y monolíticos entes como la IEEE y el PMI son los opresores del mundo del software, se desprende de las observaciones de Freire que los diminutos innovadores en proceso, los que alguna vez atacaron ferozmente el estilo de gestión representado por esos entes, querrán en breve emularlos para, en esencia, convertirse en ellos. Los eventos de la Scrum Alliance, por ejemplo, están pasando de ser encuentros íntimos entre personas apasionadas a convertirse en eventos con sponsors corporativos y famosos oradores, en esencia volviéndose idénticas a cualquier otra conferencia tradicional del mundo del software. El PMI, defensores del tan criticado proceso de desarrollo en cascada, se acaba de convertir en alguien que puede darnos consejo y apoyo (Ver el ensayo anterior “Cabalgando dinosaurios”). Esto no es progreso, sino regresión, o en el mejor de los casos circularidad. El espíritu revolucionario tan aparente en los comienzos del movimiento se ha desintegrado casi por completo, mientras marchamos al ritmo del incesante e hipnótico tambor corporativo.

¿Dónde encaja scrum en un paisaje de obediencia, cumplimiento y emulación corporativa? Muy probablemente será absorbido por esa cultura, diluido y comoditizado. Será agradable a la vista y al uso, de eso no hay dudas. Y en un par de décadas una nueva generación de trabajadores entre descontentos y desamparados darán inicio a la revolución una vez más.

Todos deseamos el cambio, pero la evidencia indica que no sabemos cómo conseguirlo de modo que sea profundo y, sobre todo, duradero. Tal vez reconociendo lo auténtica y omnipresente que es la opresión en medio de la cual vivimos hoy en día, enfrentando el hecho de que existe, admitiendo su presencia, logremos sacarnos de encima las cadenas a las que nos sujetan nuestras actitudes más arraigadas. Tal vez eso nos permita, al fin, empezar a pensar y comportarnos de nuevas y mejores maneras. Tal vez así podamos reinventar el mundo. O, por ahora, al menos el mundo del software.

16 de marzo de 2009

Anexo tendencioso: Elegía para un revolucionario seducido

Todo, absolutamente todo debe cuestionarse. Ese y no otro es el espíritu del movimiento. Preguntar, sistemática y concienzudamente por qué, para qué. El poder, la propiedad, las certezas, el modelo de negocio, esa manía de exprimir al cliente, la indiferencia hacia el usuario, el papel de los accionistas, el sistema de premios, quién decide sobre los sueldos, quién conoce los sueldos, cómo nos comunicamos, qué priorizamos, cómo priorizamos, dónde nos sentamos, si hay paredes, si no las hay, si se paga el café, si deben existir las oficinas, si tienen sentido los horarios, si vale la pena que compartamos un espacio físico todos los días, cuándo se trabaja, cuánto se trabaja, con quién se trabaja, quién hace qué, a qué y a quién le tememos, qué deberíamos aprender, de quién deberíamos aprender. En definitiva, entender el sentido de los lunes o perecer arrastrándonos a ciegas por el árido sendero de la inercia.

Agente de cambio, abejorro en la pared, scrum master, cualquiera sea tu nombre, pregunta hasta el cansancio, cuestiona o conviértete en parte del paisaje. Te veo preocupado en instalar herramientas y enviar convocatorias de reuniones. No gritaste a los cuatro vientos que el rey está desnudo. El sistema cruje contigo dentro. La llama se apaga. Otra vez será.

Amebas organizacionales

Como respuesta a la publicación inicial del ensayo sobre “cambio organizacional catastrófico” recibí un interesante comentario de Mishkin Berteig, quien, a modo de contraargumento, esgrimió lo siguiente: “El cambio catastrófico, cualquiera sea el nivel al que sucede, es señal de que existe una enfermedad. Como coaches, instructores y practicantes ágiles deberíamos fomentar un ciclo de crisis y victoria saludable, no un proceso de crisis, crisis, crisis, CRISIS, CATÁSTROFE, cambio”.56 No tuve mejor idea que ver en ese correo una buena oportunidad para ampliar mi opinión sobre el tema.

Cuando hablamos sobre cambio es importante ser específico. Todo cambia todo el tiempo, queramos o no. Coincido con Berteig en que la mejora necesita ser continua, no esporádica57. Las pequeñas crisis que detonan aquellos cambios que permiten alcanzar la mejora son oportunidades de aprendizaje, siempre y cuando las reconozcamos y reaccionemos ante ellas más temprano que tarde. Estas crisis iluminan el camino, permitiendo que aprendamos, nos adaptemos y eventualmente mejoremos.

No estoy diciendo que el cambio deba ser catastrófico; lo único que hago es manifestar que muchas veces sí lo es y que, si tratamos de evitar ese tipo de cambio, terminaremos sin cambio alguno o con algo incluso más nocivo, “el cambio fingido” o “superficial”.

Hay diferentes niveles de cambio dentro de una organización, incluyendo el cambio a nivel de equipo y personal. Berteig tiene razón en ese sentido: el cambio catastrófico a nivel de equipo no es ni necesario ni deseable. Los equipos (sin duda aquellos que practican scrum) trabajan junto a líderes o coaches y se autoorganizan; sea como sea trabajan enmarcados dentro de un framework claro y sólido de inspección y adaptación, que promueve un frecuente proceso de escucha, calibración y ajuste. No veo ningún valor en promover el cambio catastrófico en un equipo antes de que se percaten de que el cambio es necesario. Como coaches, facilitadores y educadores podemos guiar a los equipos de forma tal que sean capaces de reconocer de forma temprana las alertas. Podemos y lo hacemos. Al fin y al cabo es la razón por la cual nos contratan.

Las ideas alrededor del cambio personal, en cambio, no las tengo tan claras. Habiendo pasado yo mismo por cambios catastróficos a nivel personal, sé muy bien que no son nada apetecibles. También aprendí que a veces las cosas son como son y que haber pasado con relativo éxito a través de ese oscuro túnel puede ser una experiencia tan profunda como reveladora. La mayoría de nosotros carecemos de coaches personales que intenten guiar tanto nuestro pensamiento como nuestro comportamiento del mismo modo que nosotros guiamos equipos. Me pregunto si, aunque lo tuviéramos, seríamos capaces de escuchar sus incómodos planteos. No solemos ver ni mostrar lo que sucede dentro nuestro. Estoy seguro que percibiríamos esa actitud como una muestra de gran debilidad. No dejamos de ocultarnos tras ridículas máscaras, de fingir, de pretender que somos lo que no somos ni queremos ser y de hablar sobre lo que no sabemos ni podemos saber. Construimos meras fachadas que nos permitan ocultar nuestros puntos más vulnerables, incluyendo todas nuestras equivocaciones. Hasta decidimos cubrir los errores de otros solo para esquivar el conflicto. Mejor que todo se vea bonito y huela a rosas, que la gente parezca agradable, que siempre haya música barroca de fondo. Es allí justamente donde se gesta, donde se cocina la catástrofe. La mayoría de nosotros elegirá no enfrentarse cara a cara con un psicoanalista, terapeuta, guía espiritual o incluso doctor hasta no llegar al punto en el que la crisis se torna tan inaguantable que ya no queda alternativa. Solemos estar al borde del precipicio de la catástrofe cuando hacemos ese bendito llamado. Admitir la derrota es, como concepto, demasiado devastador como para andar enfrentándolo a la ligera.

Siento que la naturaleza humana nos lleva a negar los problemas. Somos una especie naturalmente esperanzada, optimista. Veamos si no a lo que ocurrió tras el Huracán Katrina. Se sabía que los diques del Lago Pontchartrain estaban debilitados; se sabía que podían colapsar...pero, ahora que lo pienso, utilizar analogías con desastres naturales no siempre resulta útil. El punto es que, con una buena guía y una intervención lo suficientemente temprana, la catástrofe puede ser evitada. Este razonamiento es válido hasta cierto punto a nivel personal, pero puedo afirmar que es casi una verdad universal cuando aplicamos el razonamiento a equipos de trabajo, donde aumenta nuestra capacidad de interceptar el causante del mal ¿Y a nivel organizacional? Complicado, bien complicado.

A nivel individual y de equipo seguimos lidiando con personas, con las que podemos encontrarnos, charlar y conocer. A nivel organizacional ya dejamos de tratar con gente. Las organizaciones son como masas amorfas, a veces de dimensiones insospechadas. Se parecen mucho a esas extrañas criaturas que se pueden ver en los documentales en los que bucea incansablemente el entrañable Jacques Cousteau. A mi personalmente siempre me ha costado distinguir entre la cara. De la criatura, no del señor Cousteau, claro está. La mayoría de esos bichos ni siquiera tienen un sistema nervioso central. Suele existir en toda organización una persona formalmente a cargo, pero muy a menudo su liderazgo no tiene más que un puesto y un interesante salario como respaldo. Peor aún, esta persona suele rendir cuentas ante una junta directiva y un grupo de accionistas que, de tan alejados del día a día, de cualquier pasión que pueda existir en la organización, se convierten en dictadores caprichosos e inaccesibles ¿Con cuál de los orificios que ofrece la masa será más conveniente interactuar? ¿Quién o qué cosa toma realmente las decisiones que provocan los cambios sustanciales?

El cambio organizacional catastrófico no ocurre porque nos guste, sino que sucede porque todavía no sabemos a ciencia cierta cómo generar cambios de forma sostenida en grandes organizaciones. Estamos embarcados en una travesía repleta de descubrimientos y decepciones. Qué le vamos a hacer...

El cambio organizacional es harina de un costal increíblemente distinto al del cambio personal y de equipo. Cada tipo de cambio debe ser considerado en su propio contexto. Flaco servicio es el que nos hacemos si decidimos juntarlos en un solo razonamiento, asumiendo erróneamente que pueden ser encarados utilizando una única estrategia.

El cambio personal suele requerir un despertar de la conciencia, que será muy diferente en cada individuo. Como facilitadores podemos generar el espacio de trabajo que guíe y brinde apoyo a ese proceso, pero no podremos jamás iniciarlo por motu propio.

Volviendo a la perspectiva de grupo, sí creo que el modelo de “crisis y victoria”, basado en la idea de ciclos cortos de inspección y adaptación, es el modelo a seguir si al mismo tiempo logramos introducir los conceptos y la disciplina ágil en las grandes organizaciones. Igualmente no creo que sea sano mentirnos a nosotros mismos, ilusionándonos con que el cambio a nivel equipo se propagará naturalmente hacia arriba en la organización. Presiento que nada de eso ocurrirá.

15 de diciembre de 2005

Anexo tendencioso: Democracia directa ó neuronas para la bestia

La ameba no piensa, no siente, no razona, apenas si sabe crecer, alimentarse y reproducirse. La mayoría de las organizaciones son necias, inerciales, instintivas, salvajes. El pensamiento sistémico, cuyas bases debo admitir desconozco casi por completo, propone que la organización aprenda. Lo que me dice el instinto es que, antes de saber aprender, tal vez valga la pena saber decidir.

¿Qué proyectos hacemos? ¿Cuáles dejamos de hacer? ¿Invertimos en marketing? ¿Priorizamos nuestros propios productos? ¿Compramos máquina de café o batidora de frutas? ¿Mudamos la oficina a los suburbios? La ameba hoy en día decide a través de individuos o por pura inacción ¿Qué tal si empezáramos a preguntarle a quienes la integran? Votación, votación todo el día, a toda hora. Democracia líquida, con delegación temporal y escalonada58. Voto solamente sobre los temas que me interesan. Discuto, aprendo y decido en grupo. La bestia evoluciona, una sinapsis a la vez. Probemos, rompamos de una vez el cascarón.

Yendo en círculos

Recientemente me mudé a un nuevo apartamento y lamentablemente no hay día en el que no me vea obligado a pasar con el auto por una intersección absolutamente incomprensible, no apta para consumo humano. Ha logrado exasperarme tanto que decidí tweetear lo siguiente con verdadera furia: “La ciudad de Palo Alto no entendió absolutamente nada. Una rotonda con señales de Pare es como un equipo autoorganizado que tiene un manager”. Pensando que no podía ser la primer persona que juzgaba ridícula una disposición semejante, decidí leer más sobre las rotondas, tan usuales en Europa pero tan escasas en Estados Unidos (y tan tristemente incomprendidas en Palo Alto).

Encontré un documento maravillosamente instructivo, publicado por el Insurance Institute for Highway Safety (IIHS), que describe los enormes beneficios (y las pocas limitaciones) que tienen las rotondas. Descubrí que la planificación vial es una fascinante metáfora a la hora de describir la cultura organizacional.

Los signos de Pare representan nítidamente un sistema controlador, inundado por la desconfianza. En Palo Alto, por ejemplo, hay signos de Pare en prácticamente todas las intersecciones...pero no en todas. Esto termina por confundir a los antiguos residentes, lo que aumenta la probabilidad de que ocurran accidentes. Es como si todo el tiempo nos estuvieran diciendo cómo tenemos que actuar, qué tenemos que decir, hasta que, de repente, alguien nos dice “¿Sabes qué? Haz lo que quieras” ¡Horror! Cada vez que cruzo una de esas excepcionales intersecciones temo que la persona que viene por mi izquierda no se dé cuenta de que tengo la prioridad. Difícil confiar en la gente en un ámbito en el que se cultiva la desconfianza.

¿No sería interesante si no hubiera ni un sólo cartel de Pare? Me gustaría ver una ciudad que simplemente confía en que la gente maneje de forma responsable, aportando apenas algunas guía que sirvan para asistir al proceso (como rotondas, badenes, etc.). Al fin y al cabo no creo que haya mucha gente que desee morir en un accidente vial. Y antes de gritar desesperado y a los cuatro vientos que algo así jamás funcionaría, miremos las estadísticas. Ya sabemos que la implantación de rotondas reduce considerablemente la cantidad de colisiones en una intersección. Por ejemplo:

Diversos estudios sobre intersecciones que fueron reconvertidas en rotondas en Europa y Australia han reportado[...]reducciones de entre el 45 y 75 por ciento en colisiones que hayan provocado lesiones serias.59

Muy interesante. Parecería ser que confiar en la responsabilidad de los conductores en vez de mantenerlos bajo un estricto control salva vidas. Me pregunto cómo se verían las estadísticas sobre “colisiones” en compañías basadas en el control y la obediencia ¿Será la agilidad la rotonda del mundo corporativo?

Las rotondas abundan en Europa, con alrededor de 30.000 solamente en Francia para el año 2010, y muchísimas más fuera de Europa en países como Australia, Nueva Zelanda, Emiratos Árabes Unidos, Qatar, Malasia y Costa Rica ¿Qué habrá pasado para que Estados Unidos quede tan atrás a la hora de decidir cómo un país maneja el tránsito? En buena parte el problema yace en una profunda resistencia a todo cambio, arraigada de manera profunda en la cultura. El New York Times llamó a las rotondas “la perdición de miles de conductores” en 2007.60

El mismo diario decidió luego aportar cifras concretas: “En total existen aproximadamente 2000 rotondas [en los Estados Unidos], la mayoría de las cuales fueron construidas en la última década”, para luego citar a Eugene R. Russell Sr., profesor de ingeniería civil en la Kansas State Univesity y presidente del grupo de trabajo a nivel nacional dedicado a rotondas, de la siguiente manera: “Hay mucho de lo que yo llamaría oposición irracional...la gente simplemente no entiende las rotondas”.61

Luego de leer frases como esas, comencé a preguntarme qué hay detrás de tanta resistencia. Por qué es que los urbanistas norteamericanos se resisten al concepto, mientras que en otros países adoptan la idea sin reparo alguno ¿Será pura resistencia a las ideas de otros? ¿Tal vez incapacidad para tomar decisiones rápidas? ¿O peor aún, tendrán reticencia a soltar el control? Continuando con la investigación, decidí leer la opinión de la IIHS sobre las dificultades a la hora de construir rotondas:

A pesar de que los beneficios de tener rotondas, como un incremento en seguridad vial y altos niveles de aceptación por parte del público una vez que han sido construidas, están más que demostrados, algunos estados y ciudades son reacios a su implementación, incluso llegando a oponerse firmemente a la misma. El principal impedimento es la percepción negativa por parte de algunos conductores y funcionarios electos. Las agencias de transporte han estado acostumbradas durante mucho tiempo a instalar señales de tráfico y puede tomar tiempo cambiar prácticas de diseño tan profundamente enraizadas.62

Qué frase más increíblemente apropiada. Sin mucho cambio, esto se podría reformular en nuestro contexto de este modo: A pesar de que los beneficios de la agilidad, como la mejora en la productividad o los mayores niveles de satisfacción de los clientes una vez construido el producto, están más que demostrados, algunas organizaciones son reacias a su implementación, incluso llegando a oponerse firmemente a la misma. El principal impedimento es la percepción negativa por parte de algunos desarrolladores y gerentes. Las organizaciones más tradicionales han estado acostumbradas durante mucho tiempo a instalar procesos controladores y puede tomar tiempo cambiar prácticas de gestión tan profundamente enraizadas.

18 de agosto de 2009

La cuchilla del agente de cambio es delgada y filosa

Destazando un buey

Por Chuang Tzu

El cocinero del príncipe Wen Hui

estaba destazando un buey.

Extendió una mano,

bajó un hombro,

apoyó un pie,

presionó con una rodilla.

El buey quedó deshecho.

Con un susurro,

el brillante cuchillo de carnicero murmuraba

como un viento suave.

¡Ritmo! ¡Cronometración!

¡Como una danza sagrada,

como las antiguas armonías!

“¡Buen trabajo!”, exclamó el príncipe.

“¡Su método es impecable!”

“¿Método?”, dijo el cocinero

dejando a un lado su cuchilla.

“¡Lo que hago es seguir el Tao

más allá de todo método!

Cuando empecé a

destazar bueyes,

veía ante mí

al buey entero,

toda una masa única.

Después de tres años,

ya no veía aquella masa.

Veía sus distinciones.

Pero ahora ya no veo nada

con los ojos. Todo mi ser

aprehende.

Mis sentidos están ociosos. El espíritu,

libre para trabajar sin un plan concreto,

sigue su propio instinto

guiado por una línea natural.

Por la abertura secreta, el espacio oculto,

mi cuchilla no encuentra su propio camino.

No atravieso ninguna articulación,

no corto hueso alguno.

Un buen cocinero necesita cortador nuevo,

una vez al año. Corta.

Un mal cocinero necesita uno nuevo

todos los meses. ¡Él mutila!

Llevo utilizando esta misma hoja

diecinueve años.

Ha destazado

un millar de bueyes.

Su hoja sigue cortando

como si estuviera recién afilada.

Hay espacios entre las articulaciones;

la hoja es delgada y cortante:

cuando esta delgadez

encuentra aquel espacio,

¡hay todo el sitio que se pudiera desear!

¡Pasa como una brisa!

¡Por eso mantengo esta hoja desde hace

diecinueve años

como si estuviera recién afilada!

Cierto es, en ocasiones hay

articulaciones duras. Las siento venir,

entonces me detengo, observo con atención,

me contengo, casi no muevo la hoja,

y ¡zas! la parte se desprende

cayendo como un trozo de tierra.

Entonces retiro la hoja,

me quedo quieto,

y dejo que la alegría del trabajo

penetre en mí.

Limpio la hoja

y la guardo.”

El príncipe Wan Hui dijo:

“¡Eso es! ¡Mi cocinero me ha mostrado

como debiera vivir

mi propia vida!”

He admirado desde siempre el poema taoista Destazando Un buey63 de Chuang Tzu. Hace poco reconocí en su escritura un patrón que describe con gran precisión la manera en la que prefiero introducir la agilidad en una organización. El poema habla por sí mismo en ese sentido, pero quisiera de todos modos agregar unas palabras a modo de comentario, a fin de poder ubicarlo mejor en contexto.

Cuando nos encontramos por primera vez frente a frente con una organización, se nos aparece como una masa inasible (o como una ameba, como fue descrito en un ensayo anterior). Una vez que comenzamos a trabajar junto a los individuos que la componen (sobre todo, aunque no exclusivamente con aquellos que componen su estrato inferior), las diferencias salen a la luz. No todo es lo mismo. Distintas líneas, canales de comunicación, varios puentes empiezan a emerger, así como también se zambullen ante nuestros ojos los distintos bloqueos a los que se enfrenta el deseo de comunicarse. El flujo de la organización (o la falta del mismo, claro) empieza a manifestarse con gran claridad.

Cuando estamos en esta etapa es tentador creer que las soluciones son obvias, lo que produce la gran tentación de aterrizar con consejos precisos y empezar a revolucionar todo. Ojo, tal vez sea demasiado pronto. Como el cocinero en el poema, necesitamos esperar hasta “no ver nada”, para así empezar a aprehender el mundo que nos rodea de formas completamente novedosas. Tal vez de ese modo las soluciones se encuentren por si solas, sin nuestra intervención. He aquí cómo fluye la vida.

Con el suficiente espacio y confianza, la gente comenzará inevitablemente a actuar de la manera correcta; está en nuestra naturaleza la búsqueda incesante de la harmonía. Cuando la hoja de la cuchilla es “delgada y filosa”, prácticamente no hace daño alguno: es invisible. Como coaches, tal vez todo lo que necesitamos a veces es hacer una pausa, prácticamente no mover la cuchilla y simplemente ver cómo desaparecen las barreras. Es imposible alcanzar ese estado sin tiempo ni confianza, lo que implica que se requiere mucho trabajo para dejar preparado el terreno sobre el que se construirá el sendero.

El proceso comienza simplemente escuchando en silencio y no con instrucciones amenazantes y a los gritos.

23 de diciembre de 2005

Anexo tendencioso: Facilitación guiada por el dolor, el nombre de mi cuchilla

Allá lejos y hace tiempo decidí llamar a la primer versión de este enfoque “el talibán agazapado”. Ese era yo, sin dudas. La agilidad era el único dios y scrum su profeta. Lo único que debía hacer era esperar, hacer la preguntas correctas, filosas, que el dolor subyacente emerja, para luego proponer triunfante el camino correcto, la luz. Hoy en día mi método es parecido, pero distinto.

No tengo formación alguna en coaching, a lo sumo dos décadas como paciente de psicoanálisis. La intuición me dice que la respuesta no la tenemos ni la propia organización ni yo. Pregunto, pregunto mucho, de formas incisivas, aunque sin reproches ni altanerías. La pregunta persigue como gran objetivo entender qué duele y por qué. Si lo intuyo, busco confirmación. Si no, puro diálogo indagatorio. La velocidad del cambio la dictará la fertilidad del terreno, dada en buena parte por la capacidad de autocrítica y reflexión de los individuos. La humildad como chispa, la pasión desenterrada como motor. Lo acepto, todavía me canso al destajar al buey, pero el esfuerzo ya es menor y el carpaccio mucho más apetitoso.

Adopción de scrum:
el despertar

¿Qué hace falta para que una organización cambie radicalmente la forma en la que trabaja y abrace con fervor una nueva forma de ser, en particular una tan diametralmente distinta a la actual como lo es scrum? Creo que lo que se requiere es un despertar, una especie de revelación, que se manifiesta usualmente de tres maneras distintas, pero entrelazadas y complementarias: honestidad, apertura mental y voluntad. Aquellos que se encuentren familiarizados con el tratamiento de las adicciones habrán reconocido estos tres atributos como claves para comenzar una recuperación64. Drogadictos, organizaciones disfuncionales...no hay tanta diferencia como uno quisiera pensar.

El primer requisito: Honestidad

Una organización fracturada, que sufre los costos y la deshumanización que surgen como consecuencia de vivir bajo una cultura del control y la obediencia —en la que se embarcaron, no tengo dudas, con las mejores intenciones y bajo la profunda creencia de que ese enfoque traería los mejores resultados—necesita primero de todo admitir la derrota más absoluta. Esto, por supuesto, requiere un nivel tal de honestidad difícil de encontrar. Claro está que lo que quiero decir cuando digo que “la organización” admita la derrota es que los que están a cargo sean los que lo hagan. Pero no tiene sentido responsabilizar solo a los líderes, sino que necesitamos que todos y cada uno de los empleados dé un paso al frente en este sentido. Pocas organizaciones saldrán en la búsqueda de una forma realmente nueva de trabajar sin antes haber admitido brutalmente la derrota. Lo más usual es la búsqueda de parches, pequeños arreglos, cambios superficiales, bajo la creencia demencial de que si la gente trabajara más duro y obedeciera más, si los jefes fueran más estrictos y tuvieran todo más bajo control, entonces sí, finalmente y para siempre, todo iría acorde al plan.

Eso sí, no quisiera que me malinterpreten. No estoy queriendo decir con esto que solo las organizaciones que están a punto de quebrar y dejar a todos en la calle son las únicas que están en condiciones de adoptar scrum. Un adicto no tiene por qué estar a las puertas de la muerte para comenzar el proceso de recuperación. Tocar fondo es algo muy personal, único y relativo. Una vez escuché a un alcohólico en recuperación que, cuando les preguntaron cómo supo que había tocado fondo, respondió simplemente “dejé de cavar”. Cuando dejamos de cavar podemos enfocarnos en todo aquello que no es el pozo. Podemos, al fin, mirar al cielo y ver las estrellas.

El segundo requisito: Apertura mental

Una vez que una organización admite abiertamente que se encuentra recorriendo el camino equivocado, abre su mente (colectiva) a nuevas posibilidades. Generalmente esto representa un verdadero salto de fe, sobre todo cuando las “nuevas posibilidades” son aún desconocidas. Estar abierto mentalmente a una dirección que a lo sumo podemos identificar como “algo distinto” suena aterrador para más de uno. Es cierto que muchas organizaciones ya han escuchado sobre scrum y el resto de la parentela ágil. Lo que también es cierto es que esas historias están plagadas de imprecisiones, alimentadas por un verdadero cóctel de mitos, historias terroríficas de anarquía y rebelión, hippies new age que obligan a la gente a tomarse de la mano y decir lo que siente, publicidades exageradas sobre aumentos siderales de productividad y promesas difícilmente cumplibles resumidas en la frase “rápido, bueno, bonito, barato”. Requiere mucho coraje, o un estado de gran desesperación, para esta abierto mentalmente cuando nos enfrentamos a lo desconocido.

El tercer requisito: Voluntad

Una organización que ya admitió la derrota y cuya única posibilidad de redención es algo tan radical y malentendido como scrum, se enfrenta a un enorme dilema: si bien no hay vuelta atrás, es arriesgado avanzar. Sin la voluntad de probar algo diferente, sólo se puede permanecer en el sitio. La organización puede arrastrar penosamente sus pies como lo venía haciendo hasta ahora, hundiéndose lentamente mientras otros competidores más ligeros se elevan y logran capturar su porción de mercado, o puede elegir cambiar. La voluntad no siempre es una elección, sino que a veces simplemente aparece por falta de una mejor alternativa. A veces la adopción de scrum surge más del resignado “Qué demonios, si no queda otra” que de un contagioso “¡Suena genial!”. Sea como sea, la voluntad de al menos explorar este nuevo paradigma ofrece esperanza donde antes había solo frustración y desesperanza.

Claro está que estos tres atributos no bastan por si solos, pero sí los considero imprescindibles para que una organización alcance un estado de conciencia, lo que le permitirá explorar scrum de un modo holístico. Como ya lo dije anteriormente, la derrota más absoluta no es el requisito, sino más bien el deseo de dejar de cavar, o lo que es lo mismo, dejar de actuar del mismo modo que siempre esperando otros resultados. Aquellos que no desean cambiar sus modos, que pretenden utilizar scrum como un mero remiendo, como un simple parche que permita que su proceso de siempre sobreviva tal cual, sin moverse un ápice de su añeja y arrogante postura, encontrarán exactamente lo que buscan: una solución hecha con alambre, temporal y para nada sostenible. Aquellos que inician su trayecto admitiendo su derrota con total honestidad, con una gran apertura hacia nuevas ideas y con la voluntad de abrazar nuevos paradigmas tendrán más chances de tener éxito a largo plazo. En algunos círculos de coaching esta situación se denomina “breakdown” o simplemente “colapso”. Es importante entender que la sensación de completa impotencia y desamparo que sentimos en ese momento es temporal. El mundo del trabajo del conocimiento está cambiando; aquellos que estén dispuestos a dejar de lado sus antiguos preconceptos y abrazar este cambio descubrirán rápidamente un nuevo poder—un poder nuevo y más sustentable, basado en el respeto, la confianza y la pasión por crear.

Una vez que una organización tiene la voluntad de entregarse a todo aquello que scrum tiene para ofrecerle, su gente deberá entrar en acción, para comenzar a construir su propia y única organización scrum.65 Necesitarán ayuda, de eso no hay duda. Esta ayuda la pueden obtener, obviamente, de parte de consultores, pero quiero destacar que es aún más importante la que puedan obtener de la propia comunidad ágil.

Busquen grupos ágiles locales o foros en línea. Conozcan compañeros de ruta, que se encuentren en distintas fases de “recuperación organizacional” y averigüen qué hicieron para superar los distintos impedimentos a los que se enfrentaron. Nada mejor que aprovechar el conocimiento colectivo que se ha venido acumulando en la conciencia ágil en todos estos años. Eso sí, prepárense para adoptar, aún desde un comienzo, no solo el framework scrum, sino sobre todo sus valores y principios subyacentes. Tal vez el principal beneficio de ello sea que promueve la construcción de una comunidad autoorganizada, basada en la confianza, dentro de la propia organización. El framework o proceso solo servirá como simple apósito. Una transformación genuina requerirá limpiar profundamente las heridas y hasta un eventual despertar espiritual. Nadie dijo que esto iba a ser fácil.

3 de julio de 2010

Cultura de equipo o cultura de proyecto

He venido escuchando durante años que scrum es deficiente a la hora de gestionar grandes proyectos (algunos dirían que para gestionar cualquier tipo de proyecto) y mucho se ha escrito sobre la necesidad de una gestión ágil de proyectos o sobre la implementación de un enfoque tipo lean o kanban para mitigar esta aparente deficiencia. Escuchamos a menudo que muchas implementaciones deficientes de scrum se arreglan con el agregado de uno o más de estos último enfoques, o incluso combinando scrum con un método predefinido (ej. cascada). No solo no dudo de estos casos de estudio, sino que de hecho estoy de acuerdo en que scrum es un enfoque mediocre para gestionar proyectos.

Lo verdaderamente interesante, creo yo, es lo atascados que estamos en la idea de que los proyectos deben ser gestionados—o incluso en la sola noción de que deban existir los proyectos. Mientras nos aferremos a nuestra mirada del mundo a través del cristal del proyecto, scrum nunca será una solución apropiada. Incluso quisiera sostener que ninguna de las otras alternativas sugeridas anteriormente resultaría mucho mejor. En tanto sigamos intentando agregar capas de agilidad sobre cimientos que resultan esencialmente incompatibles, seguiremos viendo éxitos parciales—y sobre todo una veloz y repentina vuelta al statu quo al más mínimo indicio de pánico. Para que cualquier iniciativa genuinamente ágil funcione, necesitaremos un absoluto salto de paradigma en la forma en la que encaramos el trabajo.

Allá por los años setenta, o incluso antes, el mundo del software adoptó lo que podríamos denominar una “cultura de proyecto”. Esto significa que el proyecto es el rey y la gente debe servirlo cualquiera sea el precio. Los proyectos tienen gestores y, claro está, si agregamos más gestores tendremos más proyectos y, por ende, haremos más cosas a la vez. Esa es la lógica. De ahí a que las personas sean consideradas “recursos” hay solo un paso. Lo que buscarán con frenesí los distintos gestores de proyectos son empleados, individuos cuya dedicación termina descuartizada por múltiples intereses. En la cultura del proyecto el equipo como tal es una entidad débil, desmantelada a menudo, en cuanto cambien las prioridades y ese conocimiento y experiencia en particular se necesiten en otro lado.

La cultura de proyecto atenta contra un principio básico del trabajo hecho con calidad: el foco en la tarea. Cuando zarandeamos al individuo de proyecto en proyecto estamos pagando un enorme costo como consecuencia del cambio permanente de contexto, lo que determina una increíble baja en la productividad. En los experimentos más básicos que llevé a cabo con pequeños grupos este costo ronda entre el 30% y el 50%, pero estoy seguro que estos números se elevan en entornos de trabajo más complejos. Al crear semejante caos, no nos quedará otra alternativa que contratar incluso más gestores, que puedan “aprovechar al máximo los recursos existentes”. Mover a la gente de aquí para allá, asignar tareas, seguir su ejecución. Harán falta gestores disciplinados, meticulosos y atentos al detalle, y conseguir esa gente no va a ser nada barato. La cultura de proyecto crea problemas que intentamos resolver profundizando esa misma cultura de trabajo. Me recuerda a la primer regla de la mala gestión definida por el “psicólogo del software” Gerald Weinberg: “Si una práctica no funciona, insista con ella”.66

Una posible alternativa a la cultura de proyecto es la cultura de equipo. En ella los equipos son siempre multidisciplinarios y, ante todo, estables, lo que deriva indefectiblemente en mayor foco y, por ende, en un mayor desempeño. En una cultura de equipo no se asignan individuos a proyectos—¡ni siquiera se asignan equipos! Directamente no existe la asignación, sino que los equipos tienen la iniciativa, tomando trabajo que se corresponda con sus habilidades e intereses. Traten de visualizar una lista claramente priorizada de todos los proyectos de una compañía (o productos, subproductos, funcionalidades), dispuesta de forma tal que todos los equipos puedan verla. Cuando un equipo termina un proyecto, simplemente toma otro—seguramente el que más se ajuste a las habilidades e intereses de los miembros del grupo.

Idealmente los proyectos (tal como se hace con las historias) serán lo más pequeños que sea posible; muchas veces se utiliza el término Minimum Marketable Feature (MMF o característica mínimamente comercializable) para describir estas tajadas de funcionalidad. Tal vez un equipo tome para si muchos MMFs que permitan luego obtener un producto o tal vez diversos equipos trabajen sobre el mismo producto, eligiendo un MMF a la vez, de acuerdo a sus conocimientos y habilidades. En definitiva poco importa el enfoque que tomemos, siempre que trabajemos utilizando reflexión de modo continuo, de modo que estemos en permanente realineamiento con clientes y usuarios. Lo que es una realidad es que si el equipo toma las riendas, el trabajo se hará bien. El principio de autoorganización nos dice que aquellos que hacen el trabajo son los más indicados para decidir cómo encararlo. Eso, creo yo, incluye antes que nada decidir de qué trabajo deberían encargarse.

La cultura de equipo propone un enfoque simple para resolver un problema complejo. Elimina el innecesario costo asociado con la asignación de personas y fomenta una alternativa mucho más enfocada al trabajo real. Escaparse de la locura del cambio permanente de contexto trae dos consecuencias más que deseables: i) elimina una buena parte del trabajo improductivo—que originalmente era desperdicio, lo que llevará a terminar más productos en menos tiempo y ii) los empleados encuentran motivación de un modo nuevo, sano e inspirador. Eliminar el trabajo improductivo también abre la puerta a transformar de una vez por todas el concepto de “tiempo muerto” en “tiempo vivo”67, durante el cual los desarrolladores pueden afilar sus hachas, investigar, inventar y, por fin, jugar un poco. Las empresas que entregan esa clase de libertad tienden a funcionar mejor que aquellas que procuran que sus empleados no tengan un segundo de su tiempo sin una asignación clara. Google, con su famosa política por la cual entrega a sus desarrolladores 20% de su tiempo para “trabajar en algo que les interese a nivel personal” es un ejemplo de una compañía que logró un éxito impresionante a través del ejercicio permanente de la confianza y el empoderamiento.

Creo firmemente que scrum fomenta una cultura de equipo. Scrum arranca con un equipo multidisciplinario que acepta trabajo de tipo transaccional, que deberá ser terminado antes de pasar al siguiente ítem. Fijar la variable tiempo ayuda a limitar la cantidad de trabajo que toma un equipo por vez. Los equipos más eficaces suelen usar el principio de kanban de limitar el trabajo en progreso (WIP o Work-In-Progress). Algunos equipos inclusive deciden no comprometerse en absoluto, sino que simplemente toman historias según lo permita su límite de WIP y procurando no iniciar trabajo que no pueda ser terminado dentro de un sprint. Lo importante en definitiva no es si un equipo toma compromisos, o cómo lo hace, sino que lo que tenemos son equipos multidisciplinarios que colaboran con aquellos que realizan las peticiones, administran sus tiempos y ponen el foco en concluir el trabajo que iniciaron.

Si las organizaciones que desean adoptar scrum estuvieran dispuestas a adoptar una cultura de equipo se darían cuenta que muchos de los problemas asociados con la gestión de proyectos desaparecerían. Podrían reducir costos de gestión (de proyectos), dejar de contratar consultores para que arreglen lo que rompieron sus antecesores y ver cómo finalmente emerge delante de sus ojos una organización ágil y eficiente. Confíen en sus equipos. Es tan simple...y tan terrorífico.

17 de abril de 2012

Anexo tendencioso: El huevo de la serpiente

Concuerdo mayormente con lo dicho en el ensayo: si el ciudadano del mundo organizacional es el proyecto, el equipo no es más que un bastardo de barro que nace hoy y muere mañana. Sin equipo no hay scrum, por lo que vale la pena detenernos sobre este punto si el framework nos interesa en lo más mínimo. Ahora, la pregunta que Tobias pospone aquí es para mí la cuestión primigenia, el origen de la virtud o la perversión. La pregunta del millón será entonces: “¿Quién decide sobre la composición de los equipos?”

Sean de credo ágil o predictivo jerárquico, todas las organizaciones con las que me he topado hasta ahora eligen quién integra los equipos utilizando el mismo dispositivo: el dedo índice de algún jerarca ¿Por qué será esta la manera más obvia, incluso en organizaciones que se ven a si mismas como verdaderamente ágiles? ¿A qué le tenemos miedo? ¿Creemos en la autoorganización o qué?

La mecánica que propongo es simple. Pero antes repitamos en voz alta: la autoorganización no equivale a la ausencia total de límites. Imaginemos un departamento de sistemas medianamente grande. Quinientas, tal vez mil personas. Decidimos de antemano qué clase de equipos necesitamos. Este debate es previo y también puede llevarse a cabo de una forma democrática. Aquí deberemos definir básicamente qué habilidades deberá haber en cada grupo. Ahora juntamos a todo el mundo en una gran habitación. Marcamos en el piso con una cruz los distintos equipos que decidimos tener, junto a la lista de habilidades que nos gustaría tener en cada uno. Y ahora sí, que viva la autoorganización: cada uno va a donde le parece, siempre y cuando el grupo como un todo esté cumpliendo con las restricciones impuestas en términos de las habilidades que debe haber en cada equipo.

Lo que el grupo genera será considerado una mera variación. Diabelli, Goldberg, scrum. Sacamos una foto, numeramos la variación y pedimos a la gente que varíe, experimente y encuentre una nueva combinación viable. Sacamos foto, numeramos y volvemos a jugar. Armaremos una cantidad razonable de variaciones. Cinco, diez, lo que necesite el grupo. Luego sometemos las variaciones a votación. Todas son válidas al fin y al cabo, ya que nosotros mismos pusimos las restricciones. Si están pensando en portfolios y sincronizaciones, simplemente se equivocaron de paradigma. Al cambiar de paradigma, cambian los problemas. Nunca hay que olvidar que lo que nos falta no es tiempo, sino decisiones.

Los equipos no se construyen

En el ya clásico Compassion, A Reflection on the Christian Life (“Compasión, una reflexión sobre la vida cristiana”), Nouwen, McNeill y Morrison escriben:

...surge entonces la pregunta “¿Cómo podemos construir una comunidad? ¿Qué tenemos que hacer para que ésta ocurra?” Tal vez esas preguntas provienen de un corazón ansioso y son menos prácticas y útiles que lo que suenan. Parecería ser mejor hacer una pregunta más contemplativa, como ser “¿Dónde vemos que aparece una comunidad?”

Esta pregunta reveladora me trae a la mente la imagen de muchas organizaciones que desean utilizar scrum como una simple forma de arreglo o mejora. La pregunta que suelen hacer tanto ejecutivos como gerentes es “¿Cómo construimos un equipo? ¿Cómo sabemos a quién poner en cada equipo?”. Lo que claramente están preguntando es “¿Cómo hacemos para garantizar el éxito?”.

Ante semejante pregunta mi respuesta es siempre la misma: no construyan equipos, simplemente dejen que emerjan. Las palabras de Nouwen y sus colegas son incluso más elocuentes y concretas. Su consejo es simplemente que observemos lo que hay, lo que ocurre, lo que es. Podríamos incluso poner en contexto la pregunta que plantean: “¿Dónde vemos que aparecen equipos?”. La pregunta puede ser reveladora por sí sola, dado que si no vemos que estén surgiendo equipos en nuestra organización, eso estaría sugiriendo que tenemos serios problemas de compromiso, pertenencia, autonomía, colaboración y confianza. Si estos valores faltan, agregar un algo que supuestamente va a “mejorar nuestro proceso” tiene poco significado en sí mismo. No lo duden, ese algo fracasará.

¿Están germinando equipos en sus organizaciones? ¿Cómo saberlo? Levanten la cabeza y busquen gente que deja sus cubículos durante largos ratos para trabajar con otros, discusiones acaloradas sobre un producto o método, conversaciones interdisciplinarias (¡desarrolladores acercándose a los testers y viceversa!), reconocimientos en público de la calidad del trabajo y las ideas de otros, risa, debate, disenso, preguntas incómodas, almuerzos en grupo, escucha respetuosa, reconocimiento, confrontación directa (más que queja indirecta), dolor, ira y frustración. Claro, no todos son fenómenos positivos de por sí, pero en todos los casos son indicadores de compromiso, de pasión. Cuando algo de esto sucede, la gente claramente se preocupa por su trabajo y sobre todo por el otro. Si algo de esto sucede, no lo dejen ir. Abrácenlo, aliméntenlo.

Si tu organización está construida en base a empleados eficientes, callados, obedientes, que están esperando la siguiente orden, la siguiente tarea, para poder terminar su parte y pasarle la posta a otro; si tu organización está constituida por individuos dóciles, que hacen sin cuestionar, agachando la cabeza, en silencio, temerosos de una eventual represalia si llegasen a hablar, entonces seguro que allí no germinarán los equipos. La pregunta correcta debería ser entonces “¿Cómo liberamos a la gente?”. Claramente una pregunta que debe aparecer en escena siglos antes que el catastrófico y popular “¿Cómo construimos equipos?”

26 de febrero de 2012

Anexo tendencioso: El jardinero fiel

El buen ejecutivo ágil no es ni líder ni gerente: es un mero jardinero, humilde y sabio. Sabe elegir semillas, combinar especies, regar cuando corresponde, respetar los tiempos de la naturaleza, ayudar con una guía cuando la planta lo requiere. Será por temor, será por desconocimiento, pero el líder tradicional suele leer la palabra “emergente” como equivalente a “salvaje”. El buen jardinero trabaja duro, no es un observador inerte. La huerta ágil no es lo mismo que el pastizal caótico.

Escalando scrum: la perspectiva del alcohólico

En la agilidad, escalar es lo último que querrías hacer

—Martin Fowler68

Todo el mundo parece querer escalar scrum. Increíblemente suele ser una de las primeras cosas que te preguntan durante un curso introductorio. Primer día, once de la mañana: “Sí, claro, comprendo, ¿pero cómo hago para que esto funcione con 5000 personas distribuidas en 27 lugares distintos alrededor del mundo?”. Lo entiendo, no crean que no. Siempre existirá el deseo, sobre todo entre los profesionales del software, de encontrar soluciones para los problemas enormemente complejos, pero tenemos que entender que difícilmente tomaremos buenas decisiones si antes no comprendemos en profundidad los fundamentos.

Siempre aconsejo comprender scrum, incorporar genuina y profundamente sus bases y razones, antes de saltar mentalmente a escenarios cuasi imposibles y pretender que scrum tenga para ello una respuesta obvia y certera. Los desarrolladores de software suelen ser inteligentes, a veces hasta demasiado. Nos gusta alabar a aquellos que pueden dar enormes saltos cognitivos, incluso salteándose pasos; vemos en ello la prueba de que estamos frente a los realmente brillantes. Pero debemos entender que scrum no se beneficia, sino que se ve perjudicado cuando salteamos etapas. El secreto está en avanzar paso a paso, lentamente, aprendiendo al caminar.

Creo fervientemente que scrum puede escalar, crecer, por si solo. Lo que quiero decir es que el framework contiene todos los elementos necesarios para manejar la complejidad inherente que aparece con el tamaño: autoorganización, empirismo, priorización y timeboxing. Lo que termina sirviendo cuando queremos utilizar scrum a gran escala no es la interferencia, sino más bien el apoyo y la comprensión. Los invito a desarrollar una profunda y minuciosa apreciación de los principios y prácticas de scrum. Esto permitirá, sobre todo a aquellos que ocupan un rol de gerente, director o scrum master, retroceder y permitir que el crecimiento ocurra siguiendo los principios del framework y no según los patrones mentales preexistentes sobre aquello que está bien y lo que no lo está. Invito a todos ellos a no influenciar el cambio, sino más bien a ubicarse en la postura de guía, de quien apenas procura acompañar el proceso en su devenir, modificando distintas variables cuidadosamente para poder lograr que los objetivos de los equipos y la organización sean un todo. En otras palabras: háganse a un lado.

Recientemente he encontrado un paralelo más que interesante en la manera en la que han escalado los grupos de autoayuda: en 1935 Bill Wilson y el doctor Bob Smith formaron un grupo en Akron, Ohio, con el objetivo de ayudar a alcohólicos como ellos mismos a recuperarse de esa obsesión. A partir de este diminuto grupo autoorganizado (no había terapeutas ni líderes) creció un movimiento de alcance mundial, conocido hoy en día como Alcohólicos Anónimos ¿Cómo lograron que ocurra? ¿Cómo pudo un grupo de ex-borrachos aplicar los principios de la autoorganización para que su movimiento pueda escalar a semejantes dimensiones sin que haya habido nadie a cargo? La respuesta es simple: la solución emergió lentamente y según necesidad.

Resulta ser que un día Bill Wilson tuvo que mudarse a Nueva York, de donde era originario, y no le quedó otra alternativa que armar un grupo allí mismo. Éste creció y creció, hasta que algo similar volvió a ocurrir. Nuevos grupos fueron surgiendo a partir de las nuevas necesidades (generalmente geográficas) de sus propios miembros. Vale la pena notar que muchos grupos desaparecieron cuando la necesidad de que existan también lo hizo. Eventualmente algunos de sus participantes pensó que sería útil definir una serie de principios rectores, de forma tal de lograr mayor sensación de cohesión entre grupos tan dispares. Fue así como se desarrolló una serie de “tradiciones” que logró unir a ese colectivo a priori tan disuelto e independiente69. Quisiera citar algunos de ellos, que considero muy relevantes para esta discusión:

Nuestros líderes no son más que servidores de confianza, no gobiernan

Cada grupo debe ser autónomo, excepto en asuntos que afecten a otros grupos o a Alcohólicos Anónimos considerado como un todo

Cada grupo tiene un solo objetivo primordial: llevar el mensaje al alcohólico que aún está sufriendo

Resulta un simple ejercicio mental el poder trasladar estos principios al uso de scrum a gran escala:

Nuestros líderes no son más que servidores de confianza, no gobiernan (¡no hace falta cambiar nada!)

Cada equipo debe ser autónomo, excepto en asuntos que afecten a otros equipos o a la organización considerada como un todo

Cada equipo tiene un solo objetivo primordial: construir un incremento del producto al final de cada iteración y entregarlo al cliente (¡quien muy posiblemente está sufriendo!)

Algunos dirán que este ejemplo nos aleja lo suficiente del mundo del software como para convertirse en inútil. Tal vez les viene a la mente la noción de que un alcohólico en recuperación no es responsable en términos de deadlines 70y entregables. Yo lo pensaría dos veces. Sin AA muchos de ellos estarían simplemente muertos ¿No es la muerte acaso el más terrible deadline que puede existir? Yo diría que hasta es posible respirar el sentido de urgencia que se extiende en todos y cada uno de los encuentros de Alcohólicos Anónimos. Para muchos es el último refugio posible: o nos recuperamos juntos o morimos en soledad. Yo no desestimaría tan rápido la analogía por falta de relevancia. Lo que nos interesa aquí es cómo ha podido escalar de manera exitosa una idea de un modo emergente y autoorganizado. Los invito a buscar las similitudes, más que enfocarse maniáticamente en las diferencias.

9 de abril de 2008

Buscando consentimiento

...el consenso es bueno, aunque las decisiones son mejores. Escuchen a todas las voces, pero no sean rehenes del consenso

—Michael Spayd (@mspayd)

La mayoría de la gente apesta a la hora de lograr consenso. Tal vez deberíamos mejorar esa capacidad en vez de promover la exclusión

—Derek Neighbors (@dneighbors)

Este breve diálogo por Twitter logró llamar enormemente mi atención. Hemos discutido sobre el consenso durante años en la comunidad ágil y estas dos afirmaciones creo que logran captar la esencia de las dos líneas de pensamiento que existen al respecto. Por un lado están aquellos que creen que el consenso es la mejor manera de evitar el conflicto y el desacuerdo, para así asegurarse que todos han al menos acusado recibo de las decisiones que se alcanzaron. Por otro lado están aquellos que creen que el consenso es un lastre para la toma efectiva de decisiones. Éstos suelen promover la existencia de líderes firmes que puedan dar un paso al frente cuando el resto no logra llegar a un acuerdo. Honestamente ninguna de las dos posturas me resulta atractiva.

Si algo aparentemente tan trivial como llegar a un acuerdo sobre dónde salir a comer representa un problema para un grupo numeroso, me resulta difícil creer que sea posible acordar unánimemente sobre cuestiones tan trascendentales como la definición de los objetivos de un productos o la estrategia con la que va a ser desarrollado. Comprendo el argumento de Spayd, que en otras palabras nos está diciendo “tengamos un líder que en definitiva tome una decisión”. El problema con ese enfoque es que, con el tiempo, la voz de la minoría termina siendo silenciada y sus miembros acaban desilusionados e impotentes ¿Existirá alguna alternativa superadora?

Recuerdo con gusto el concepto de consentimiento, según lo describió el filósofo francés del siglo XIX Auguste Comte, quien fuera uno de los fundadores de la sociocracia71, una teoría de gobierno más bien radical que es aún popular en ecoaldeas, proyectos de covivienda y en varias empresas progresistas en el mundo entero. Mientras el consenso puede ser entendido como “todos están de acuerdo”, el consentimiento se describe como “nadie se opone”, lo que en términos sociocráticos se define como “falta de objeciones primordiales”. La diferencia es enorme. El consentimiento no es ni acuerdo ni aprobación. Cuando un padre brinda consentimiento para que su hija se case, no necesariamente se encuentra de acuerdo con su decisión o siquiera la aprueba. Lo que es cierto es que su consentimiento implica que está dispuesto a confiar en ella y por ende en su decisión. Sabrán disculpar lo arcaico de la analogía, pero creo que ayuda a ilustrar el principio. El consentimiento consiste en liberarse de las propias ataduras, para luego confiar en otros. Claro está, sólo puede ser alcanzado si existe esa confianza previamente. De lo contrario, puede tomar un buen tiempo llegar a conseguirlo.

En el mundo occidental consideramos que la democracia es el ejemplo más cabal de justicia y equidad. Todos tienen voz y la mayoría (la voz más fuerte) gana. Pero entendamos que cuando hay ganadores siempre tendrá que haber perdedores y donde hay perdedores hay insatisfacción. Este fragmento tomado de la maravillosa novela La Biblia Envenenada72 escrita por Barbara Kingsolver, que se sitúa durante la formación de la República Democrática del Congo en 1960, explica los aspectos negativos de la democracia y delinea con precisión, aunque accidentalmente, el modelo sociocrático de la organización circular. En él el narrador está refiriéndose a Tata Ngu, el líder tribal de la aldea de Kilanga:

Sea lo que sea que pensemos sobre este imponente hombre del sombrero de punta, es quien representa el deseo de Kilanga. Pienso que es por eso que el Hermano Fowles dijo que debíamos respetarlo, o al menos prestarle atención, por más jefe desequilibrado que parezca ser. Cuando habla no lo hace pensando solo en él. Cada pocas semanas Tata Ndu se reúne con sus subjefes, quienes a su vez se reúnen con todas las familias. Es por eso que cuando Tata Ndu dice algo, puedes estar seguro de que es la aldea entera la que te está hablando.

Anatole me ha estado explicando el sistema de gobierno indígena. Dice que todo el asunto de arrojar guijarros en cuencos y que el cuenco con más guijarros gana la elección —que era la idea belga de jugar limpio —resulta peculiar a la gente de aquí. Para los congoleses (incluyendo a Anatole mismo, confesó) resulta curioso que si alguien obtiene cincuenta votos y otro cuarenta y nueve, el primero gana por completo y el segundo pierde de forma absoluta. Eso significa que casi la mitad de la gente estará insatisfecha y, según Anatole, si media aldea está insatisfecha, no has escuchado el final de la historia aún. Es seguro que a futuro habrá algún tipo de problema.

¿Son mejores las decisiones que dejan a muchos insatisfechos? Lo dudo. En el apuro por hacer, por ver resultados, solemos dejar marcada una huella de insatisfacción. Como señala Neighbors, la mayoría de nosotros tiene dificultades para lograr consenso, pero eso no debería ser una excusa para la exclusión. La exclusión duele, lastima. Deberíamos procurar ser cada vez mejores en escuchar las distintas voces en vez de acallar a quienes objetan.

Ya puedo escuchar las quejas: “¡Pero así nunca vamos a lograr terminar nada!”. No les creo ni un poco. He visto el proceso de consentimiento sociocrático en acción y es verdaderamente hermoso —si bien en ocasiones resulta profundamente frustrante, su belleza radica en que al ocurrir crea comunidad en vez de división. Cuando finalmente se realizan acciones, éstas se llevan a cabo con cuidado y respeto por la comunidad entera y no a través de la opresión de la minoría.

En muchas ocasiones la mejor alternativa es no hacer nada, simplemente ser —esto es tomarnos un tiempo para explorar quiénes somos y qué es lo que realmente nos importa, para entender nuestros verdaderos deseos y los de quienes nos rodean, y escuchar para entender dónde reside el dolor, que es donde seguramente se enconará la ira. Si abrazamos con fervor la disonancia en los grupos y perseguimos el mutuo entendimiento, si procuramos escuchar antes que persuadir, entonces tal vez las decisiones provengan de un lugar pleno de paz y por ende serán las más beneficiosas para la comunidad como un todo.

El consentimiento requiere confianza; la confianza se obtiene a través de la comprensión; la comprensión emerge al escuchar; y escuchar requiere silencio. Si realmente quieren que su voz se escuche, dejen de hablar.

18 de agosto de 2012

El espíritu del cambio

Muchos de mis trabajos como consultor ágil comienzan con un grupo de ejecutivos que me contrata para que “[el área de] desarrollo mejore”. La idea reinante en estas organizaciones se puede resumir como “hay que arreglar a mi gente”. Pero la gente no necesita que nadie la arregle; suele suceder que ese colectivo está compuesto de individuos enormemente talentosos e inteligentes, que se encuentran entrampados en un sistema decadente e improductivo. Lo que necesita arreglo no es la gente, sino más bien el sistema.

Ahora, si bien hace tiempo que entiendo esta idea, no fue hasta que comencé a trabajar con un cliente en particular que terminé de comprender el problema de forma tal que no me sería posible ignorarlo en el futuro. Me encontraba en medio de una organización repleta de gente brillante y apasionada, cuyas ideas pedían terreno para florecer, pero se marchitaban en el intento tras ser apaleadas por un grupo de ejecutivos que parecía haber quedado atrapado en un estilo de gestión digno de los años ochenta, caracterizado por una inusual mezcla de fanfarronería, amenazas y engaños. Claramente, no existía ningún tipo de confianza en cualquiera de las dos direcciones. Se despedía gente sin previa advertencia, mientras que otros partían desesperanzados. Claro está, esperaban que todo esto se arregle con una clase sobre scrum de dos días y un par de semanas de consultoría.

En el trabajo de consultor ocurre a veces que la propia integridad se ve enormemente desafiada. Si bien había terminado de comprender la situación al concluir los dos días de capacitación, elegí quedarme las dos semanas que habíamos arreglado previamente, a pesar de lo seguro que estaba de que podía cambiar muy poco la forma en la que operaba esta organización. Mis excusas iban desde las muy cínicas, como “ya estoy aquí, así que mejor que me paguen”, hasta las más compasivas, del tipo “tal vez puedo ayudar a estos individuos a darse cuenta que existe una forma mejor de trabajar, para que así entiendan que deben dejar esta empresa”.

Cuando terminó el contrato se me pidió que vuelva tiempo más tarde. Sonaba esperanzador, aunque existía el peligro de que yo estuviese siendo funcional en perpetuar el mito de que el problema estaba en la gente. Era increíble lo claro que se veía que el verdadero problema estaba en el sistema —o tal vez, podríamos decir, en aquellos que lo crearon y luego perpetuaron, o sea los ejecutivos —los mismos que no podían otorgarme ni media hora de sus tiempo durante las dos semanas para poder hablar sobre su responsabilidad en toda esa disfuncionalidad. Si iba a volver tenía que insistir con medidas que apunten a los problemas más sistémicos, para así generar un cambio genuino. Mi propuesta incluía capacitación y coaching a los ejecutivos, los comerciales y los equipos de producto, una discusión con recursos humanos con respecto a la política de contratación y premios, y apenas un poco sobre arreglar a los desarrolladores, para que por fin hagan scrum. No me volvieron a llamar.

Fue más o menos para esa época que tomé la decisión de dejar la consultoría y procurar un rol más permanente dentro de una organización donde, tal vez con los años, podría lograr impulsar cambios genuinos a niveles más profundos, ya sistémicos. La verdad es que nunca iba a generar ese tipo de impacto como el asesino a sueldo que era.

Para ser justos con la empresa que aquí menciono, debo decir que no están solos. Son apenas un ejemplo, una muestra de la eterna mentira que se perpetúa en el mundo de los negocios: más control equivaldrá a mejores resultados. Este asombroso mito se representa cual drama absurdo una y otra vez, incluso, para sorpresa de pocos, en startups que tenían todo por inventar. Es increíble cómo se ignora olímpicamente lo que demuestran décadas de investigación sobre lo que motiva a los individuos con el solo objetivo (o al menos así parece) de que aquellos que dirigen las compañías se sientan importantes y con acceso directo al poder. Tan es así que nadie teme hacer gala de una ridícula ilusión de control.

W. Edwards Deming observó hace más de cuarenta años que en cualquier organización el sistema representa 85% del problema y la gente apenas un 15%73. Y sin embargo seguimos haciendo oídos sordos a esta observación, mientras ponemos todas nuestras energías en medir, recompensar, castigar y controlar a los individuos. Qué equivocados estamos. Las empresas en general, aunque tal vez aquellas que producen conocimiento más en particular, están compuestas de buena gente. Buena en todas las acepciones del término: capaces de hacer bien su trabajo, de buen corazón, justos; quieren que tanto ellos como sus equipos y las organizaciones a las que pertenecen tengan éxito. Increíblemente, y a pesar de todo eso, hay mucho dolor y frustración en el trabajo. Los sistemas dentro de los cuales operamos día a día están fracturados, colapsados; no son sino ruinas de tiempos pasados. Ruinas pesadas, obsoletas y sobre todo desentendidas e ignorantes en todo lo que respecta a la psicología del individuo. Lo increíble es que, aún a sabiendas de esto, nos quedamos inertes, en silencio, mientras los gerentes de estas organizaciones (gente buena también, aunque consumidos por el sistema) siguen tratando de arreglar empleados. Sin siquiera reflexionar sobre la efectividad de sus medidas, entregan premios y castigos tratando de motivar individuos profundamente desmotivados, traen consultores (como quien escribe) para que ofrezcan apósitos para el proceso como la agilidad y la variante que esté más de moda. Pero lo que necesitamos no son apósitos, sino cirugía mayor o, tal vez, simplemente psicoterapia.

Mi colega Bob Marshall acuñó el término “terapia organizacional” para describir su modo de operar: “La terapia organizacional ofrece un enfoque no directivo a la hora de abordar algunas de las disfunciones presentes en cualquier organización. Permita que la organización aumente la conciencia de si misma y su capacidad para verse a si misma con mayor claridad, para luego encontrar sus propias soluciones para sus problemas más apremiantes”.74

Creo que se ve con claridad hacia dónde apunta su propuesta. Debemos concentrarnos en llegar a la raíz del problema, destapando todo lo que incomode, enfrentando a demonios propios y ajenos, haciéndonos cargo de todo aquello que nos corresponda en este pandemónium disfuncional que llamamos trabajo. Hubo una vez en la que el movimiento ágil pareció transformarse en una posible salida de semejante desastre y tal vez lo habría sido, de no haber sido por todo su derroche de bombos, platillos, conferencias, herramientas, promociones, bravuconerías corporativas, marcas y sellos. El movimiento ágil ya demostró que es incapaz de producir semejante alteración en el mundo de los negocios. Tal vez sea hora de dejar atrás esta fachada y hacernos cargo del fracaso.

La agilidad es una idea abstracta, concretizada a través de sus distintas implementaciones—esencialmente extreme programming, scrum y kanban. Hay mucho material valioso en cada uno de estos frameworks—una especie de agitación creativa que empieza tímidamente a desafiar viejas escuelas—pero esta agitación ha sido lenta y subrepticiamente acallada por su aceptación en el mundo corporativo, hasta convertirse en una leve y sumisa variación del statu quo. Lo peor de todo es que muchos supuestos agilistas consideran este hecho como alentador, exaltando la pujante aceptación de la agilidad en todos los ámbitos e instituciones. Como comunidad estamos tan inmersos en la promoción de nuestras ideas, predicando en conferencias, escribiendo libros y ganando dinero, que hemos perdido de vista—si es que alguna vez lo tuvimos—aquello que realmente importa.

En mi caso eso sería el compromiso, el amor, la pasión, el entusiasmo, la liberación ajena, la libertad propia, la responsabilidad personal, el coraje, la curiosidad, la risa, la vida—en fin, el espíritu. Ningún framework ni proceso nos dará jamás espíritu por sí solo, así como tampoco lo hará ninguna herramienta que permita mover de aquí para allá papelitos virtuales. Tampoco lo logrará moda alguna y muchísimo menos ninguna consultora agresiva comercialmente que promete cambio genuino a los cuatro vientos mientras no hace sino acatar las disfunciones culturales existentes y amontonar una frondosa cosecha financiera. El espíritu viene de otro lugar, dentro de cada uno, y se materializa cuando servimos una causa que nos trasciende. Hasta tanto no encontremos la manera de trascender, seremos esclavos de rígidos procedimientos, promesas vacías y una rampante desesperanza.

Ya me cansé de la marca Ágil, con toda su perorata comercial y sus promesas vacías. En su lugar he decidido caminar el sendero de la agilidad genuina—elegante, curiosa y desenfadada. Me cansé de las órdenes y los resultados definidos a priori. En su lugar prefiero gritar “No tengo idea, exploremos”. Me cansé de obedecer lo que dictaminen las jerarquías severas de rostro adusto, de venerar falsos ídolos. En su lugar quiero encarar mi trabajo con un corazón generoso, mentalidad de principiante y alma de anarquista. Considero que la sabiduría para saber apreciar y abrazar el cambio, así como la capacidad para lograr un compromiso genuino, reside en cada uno de nosotros, así como en nuestra conciencia colectiva. Mi trabajo—si es que tengo uno—es simplemente abrir las puertas de la jaula, cortar las ataduras que nos tienen amarrados a una cultura difunta, para así poder despejar el terreno y crear espacio para lo que viene. Si aparece el caos, mejor así. Como los sistemas autoorganizados que son, cada equipo, grupo o empresa convergerá en el modo de trabajar, la manera de ser, que más le conviene. Lo único que necesitamos para empezar con todo esto es confiar en la bondad inherente que vive dentro nuestro y de nuestros colegas, sumado a un sincero deseo de hacer de este mundo un lugar mejor. El resto emergerá.

1ero de octubre de 2012

Anexo tendencioso: El espíritu, la savia, el camino

Caminemos, porque no hay destino. Caminemos, porque quedarse quieto es morir de aburrimiento y hastío. Plantemos nuestro propio huerto con paciencia y disciplina. Admiremos lo simple que habita dentro de la infinita complejidad de individuos, equipos y organizaciones. Avancemos, cuestionemos, disfrutemos. Vale la pena.

Apéndice I: Scrum

Un framework simple para resolver problemas complejos

Scrum como concepto es inconcebiblemente simple—demasiado simple parece—para aquellos profesionales brillantes y complejos que se supone deben adoptarlo. Frecuentemente vemos como fervientes ingenieros en procesos y aquellos criados según los lineamientos del management científico de Taylor complejizan innecesariamente el framework. Es esta complejización la que causa tantos malos entendidos y la que conduce eventualmente a una aplicación deficiente. La siguiente descripción de scrum procura entonces capturar el espíritu de esa simplicidad.

Scrum es un framework que permite mejorar la manera en la que trabajamos. Procura lograrlo fijando expectativas y límites claros—dos elementos esenciales si pretendemos que ocurra la autoorganización y emerjan las disfunciones. En scrum utilizamos un proceso iterativo, en el cual se procura que cada iteración o sprint sea tan corta como sea posible, tratando de mantener un ritmo parejo mientras pasamos por los momentos de planificación, ejecución y reflexión. El timeboxing, estricto y rítmico por naturaleza, proporciona a los equipos que utilizan scrum una asombrosa capacidad para sacar a la luz disfunciones organizacionales.

En Scrum existen tres roles (scrum master, product owner y equipo), así como también debe existir una serie priorizada de pedidos, un objetivo por sprint y una manera simple de medir el progreso. Constantemente se producen diálogos acotados temporalmente para poder planear, alinearse diariamente e inspeccionar y adaptarse una vez por sprint.

En el framework se mantiene una clara distinción entre el “qué” (el destino) y el “cómo” (el sendero). Se requiere un mucho foco, compromiso y absoluta transparencia en todos los niveles; se enfatiza la importancia de ciertos valores propios de las relaciones humanas, como ser la confianza, la integridad, el coraje y el compromiso.

Roles

El scrum master es un líder al servicio del equipo y un agente de cambio en el contexto organizacional que contiene a este último. El product owner es la principal voz del cliente, a la que representará por medio de una visión convincente y a la que se llegará por medio de un proceso de continua priorización. El equipo es un grupo autoorganizado y multidisciplinario de individuos a quien se le delegó el suficiente poder de decisión como para construir un producto que alcance la visión.

Artefactos

Un equipo scrum siempre mantiene una cola de pedidos o metas. Denominado backlog, este artefacto contiene toda la información que, al menos hoy, nos gustaría tenga nuestro producto o servicio. Es una lista viva, en estado de permanente cambio, aunque siempre ordenada por prioridades que irán cambiando con el tiempo. Los ítems del backlog siempre se enfocan en el “qué”. Los de mayor prioridad deben tener también resultados esperados claramente definidos. El compromiso del sprint es un subconjunto del backlog, a veces descompuesto en tareas menores, que describen el “cómo” que nos acercará un poco más hacia la visión del producto. En scrum se requieren también métricas simples, como ser cantidad de trabajo restante o valor de negocio entregado hasta el momento. Las métricas deberían ser usada para entender lo que ocurre, no para definir éxitos o fracasos. Solo aquellas métricas que se enfocan en mostrar la verdad de lo que ocurre podrán evitar actitudes tendientes a emparchar las debilidades.

Diálogos

El equipo y el product owner se encuentran antes del comienzo de cada sprint para definir un objetivo para el mismo y planificar su trabajo. Se espera que el equipo entregue un producto terminado que cumpla con el objetivo acordado una vez que termine el sprint. Cómo se logrará ese objetivo es asunto del equipo. Cada día los miembros del equipo se encuentran alrededor de un tablero que brinda métricas visual para intentar alinearse, así como pedir y ofrecer ayuda cuando sea necesario. Al finalizar el sprint los stakeholders y consumidores del producto revisan el resultado del trabajo realizado. Como resultado de esta experiencia, éstos podrán sugerir cambios o adaptaciones en el producto. Luego de la revisión, los miembros del equipo reflexionan sobre el proceso, buscando maneras de mejorar y comprometiéndose a intentar llevar adelante esas maneras. Todos los sprints deben concluir con un producto o servicio mejorado y un proceso más apropiado y atractivo.

Esta es, salvando algunos detalles menores, la descripción de scrum que ha circulado desde que el primer libro fuera publicado en 2001. Quité de la descripción toda referencia al software, dejé de lado algunos términos para enfocarme en los principios subyacentes y procuré condensar las reglas hasta llegar a su esencia. No agregué ni quité nada.

Apéndice II: Cómo contratar un consultor ágil

Terminaste el libro y, ojalá, inspirado por algunas de sus ideas, te estarás preguntando cómo hacer que todo esto suceda en tu organización. Hay sin duda muchas formas de arrancar, incluyendo mucha más lectura, participación activa en comunidades ágiles o de scrum y, claro está, probar y aprender sobre la marcha. También podrías llegar a contratar un consultor o coach especializado en scrum para que te ayude a empezar con todo esto. Si este fuera el caso, he aquí mi humilde guía para que logres encontrar la persona adecuada para tu organización.

La agilidad no puede ser prescripta. Tampoco hay ningún manual. En esencia no se trata de ningún proceso, sino de gente. De respetarla y guiarla hacia modos de trabajar más efectivos y llenos de compromiso. Siguiendo esa misma línea, contratar un consultor ágil (también conocido como coach) debería estar enfocado en la persona. Hoy en día muchos clientes se dejan llevar por grandes marcas o bajos precios. Ambas ideas son igual de malas. Cuando la consultoría ágil escala, se diluye, es inevitable. Las grandes agencias—aspirantes a convertirse en los Accenture del mundo ágil—bien pueden atestar tu organización de cuerpos, seguramente mucho antes que una pequeña agencia o que un consultor independiente. Incluso pueden llegar a ser más baratas ¿Pero estás seguro qué es lo que estás comprando?

Primer consejo: conocer a quien estás contratando. Y por conocer quiero decir personalmente. Contratar a una gran empresa puede redundar en el aterrizaje forzoso de un consultor, o grupo de consultores, aleatorio, del que nunca antes habías escuchado, siquiera como tímido participante de la comunidad ágil. Tal vez sea gente con limitada experiencia, formados para obedecer tanto los estándares corporativos, como a aquellos que los definieron y procuran que se sigan a pie juntillas.

He aquí algunas pautas que puedo brindarte para encontrar a la persona adecuada. Primero voy a centrarme en aspectos a evitar, para luego sí apuntar a aquello que deberías buscar.

No contrates a un anónimo

No permitas que la consultora te prometa “la mejor persona que podrías haber tenido”. Lo más probable es que el consultor que aparece no tenga la menor idea sobre tus necesidades—sí sobre lo que estás pidiendo, pero esas dos cosas suelen no ser las mismas.

No dejes que proximidad geográfica y costo sean los principales criterios en la búsqueda

Yo empezaría seleccionando gente que suene como si supieran de lo que están hablando y que poseen una trayectoria que respalde todo eso que están diciendo. No importa si viven lejos o si cuestan más que los otros. Nunca olvides que lo barato sale caro y en asuntos como éste el valor que se puede obtener de un buen consultor es exponencialmente mayor al de su contraparte baratija.

La recomendación manda

Lo mejor para comenzar la búsqueda es preguntar a amigos y colegas de diferentes organizaciones si tienen alguien para recomendar. La recomendación no garantiza nada, pero siempre es un buen respaldo, sobre todo si tienen experiencia real con esa persona. Siempre es mejor que una publicidad en Google o un correo no deseado.

Planificar con tiempo

Resulta muy útil involucrarse con la comunidad ágil por medio de la lectura de blogs y la participación activa en grupos de discusión en línea y encuentros o conferencias. Por este medio será mucho más fácil encontrar y conocer al candidato ideal.

Un poco de investigación no viene mal

¿Tiene un blog el candidato? Leerlo no está demás ¿Está en Twitter? Seguir sus tweets ayudará a conocerlo ¿Por qué debería importar todo eso? Los consultores que se involucran con la comunidad suelen ser los más ávidos a tomar riesgos, ya que no le temen a la mala prensa—basta con leer los comentarios que recibe en su blog, donde solemos discutir acaloradamente, sobre todo para incomodar al otro y desafiarlo a que encuentre nuevas maneras de ver un tema. Es importante observar cómo responde el consultor ante una crítica ¿Se pone a la defensiva o construye sobre las observaciones que recibe?

Si el consultor escribió un libro, mucho mejor, léelo, o al menos ver las críticas del mismo. Si no hay críticas, algo pasa.

Yo trataría al currículum como una mera presentación formal. Los currículums son documentos secos y vacíos cuya intención es la venta. No compres. Siempre aconsejo usar el principio de atracción por sobre el de promoción: en última instancia termina funcionando mejor la relación que se entabla con un consultar cuya voz, aunque sea por escrito, logra inspirarte de algún modo. Creo que vale la pena hacer el esfuerzo para encontrar alguien así.

Y nunca deberías olvidar para qué existe LinkedIn. Todos los consultores están en esa vidriera, por lo que seguramente han curado con dedicación su sección de comentarios y recomendaciones. LinkedIn es para la gente que quiere hacer negocios. Los blogs y Twitter son para la gente que se quiere comprometer con la comunidad.

El mejor consultor es el que sabe decir “no sé”

Muchos consultores llegan con una solución, incluso sin antes entender cuál es el problema. Curiosamente esto ocurre muy a menudo con los consultores ágiles. La agilidad, cuando se viste de algunas de sus tantas pieles, como scrum o kanban, suele ser interpretada como una loción mágica que todo lo cura. Suele imponerse un proceso y hasta, en más de un caso y cuando participan las compañías que las desarrollan, incluso se impone una herramienta. Ojo. Las herramientas ágiles suelen forzar alguna clase de proceso que podría ser (de hecho suele ser) el menos indicado para tu contexto.

Un buen consultor debería llegar con una mente de principiante. Con preguntas, no con soluciones. Inocencia, más que expertise, suele ser un buen signo. Nada hay que temer si hiciste bien tu búsqueda. Las soluciones emergerán a partir de la comprensión y el entendimiento. Un buen consultor trata de entender, no de arreglar.

Cara a cara antes de empezar

No te olvides de mirar al candidato a los ojos y escuchar atentamente cómo habla. Siempre estate atento a las conjeturas sobre tu situación que esté haciendo sin darse cuenta ¿Están teniendo un diálogo o es un discurso de venta? ¿Estás explorando y aprendiendo o simplemente comprando? Mi consejo es que sigas lo que te diga tu instinto.

Evaluación inicial antes que grandes planes

No olvides que al fin y al cabo estás contratando un consultor ágil. Sería ridículo dejar la agilidad de lado en el trabajo en conjunto. Lo básico es tener frecuentes instancias de inspección y adaptación, para poder reevaluar el plan en función del valor que viene agregando su trabajo. Debería siempre haber una manera rápida y efectiva de cortar la relación si concluyen que la misma no es conveniente para alguna de las partes.

En esencia, la responsabilidad es toda tuya. Encontrar a la persona adecuada no es simplemente un tema de “reclutamiento”, sino de interacción con gente real, para luego lograr crear valor genuino. Yo me tomaría el tiempo para hacer esta búsqueda a conciencia. En mi experiencia, el retorno de inversión va a ser muy superior.

Epílogo

Por Ángel Medinilla

Yo asesiné a Tobias Mayer.

Bueno, sí, de manera figurada. Pero, como decía Cecil B. de Mille, las películas deben empezar con un terremoto e ir creciendo en acción. Máxime cuando la película no es tal película sino el epílogo a un libro, algo que la mayoría de los lectores se saltarán por sistema. Es por ello que decidí empezar con algo que tenga opciones de capturar la atención del lector. Salvando las distancias, intento hacer algo que se acerque al soberbio comienzo de “El Ser en el Umbral” de H.P. Lovecraft: “Admito que he disparado seis balas a la cabeza de mi mejor amigo. Ahora bien, pese a esta confesión, me propongo demostrar que no puedo considerarme un asesino.”

Pero divago…

Como decía, yo asesiné a Tobias Mayer. Tampoco es que fuera el único que lo hizo. Pero para entender por qué llevé a cabo este acto tan atroz, debo remontarme unos cuantos años en el pasado. No muchos, desgraciadamente.

Corría el mes de Noviembre del año 2010 y yo empezaba a labrarme un modesto nombre en España como formador, consultor y divulgador en el campo de las entonces llamadas “metodologías” ágiles de desarrollo. Desde que monté mi empresa en 2007 había impartido varios cursos, charlas y conferencias a nivel nacional, pero decidí que tenía que ir más allá y proyectarme hacia una escena más internacional. Propuse una charla corta a la Scrum Alliance con ocasión del Scrum Gathering de Amsterdam y la aceptaron, así que allá que me fui para dar mi primer speech en inglés delante de toda la Scrum Gallery75. Estaba nervioso y se me notaba, pero me sirvió de trampolín para quitarme complejos y comenzar a ver mundo.

Para quien no los conozca, comentaré que los eventos de la Scrum Alliance en Europa son sin duda una de las grandes citas para los agilistas de nuestro continente y una gran oportunidad para conocer a otros expertos de allende los mares, aunque todavía están lejos del glamour de los eventos estadounidenses, donde es habitual encontrarse a casi todos los grandes nombres históricos de la agilidad.

Con todo y con ello, este evento fue determinante para mí como agilista y como persona. Tuve la oportunidad de conocer a un tipo al que llevaba siguiendo la pista una temporada y que acababa de escribir un brillante libro titulado ‘Management 3.0’, un tal Jurgen Appelo. En el Gathering de Amsterdam celebró uno de los primeros pilotos de su curso, si no el primero, y tuve la oportunidad de disfrutar de las primeras versiones de sus famosos juegos y ejercicios. Años después me haría formador de Management 3.0 y comenzaría una fructífera relación personal y profesional que continúa hoy en día.

Pero, mientras se celebraban las charlas y sesiones, era patente que había algún tipo de conflicto en la organización de la Scrum Alliance. No hacía demasiado que la junta directiva de la Scrum Alliance había dado un “golpe de estado” y había expulsado a Ken Schwaber. Anecdóticamente, la página de Schwaber en la Wikipedia alega que dejó la Scrum Alliance, la organización que él mismo había creado, por un accidente de bicicleta. Al parecer, el accidente no le impidió fundar Scrum.org y crear un nuevo programa paralelo de certificaciones.

Divago de nuevo…

La junta directiva de la Scrum Alliance anunció en Amsterdam que, por primera vez, esta organización iba a contratar a alguien externo para que fuese Director. Quien dice Director dice Presidente, Managing Director, CEO, Señor Oscuro del Sith o como lo llamen los americanos. Habían seleccionado a una tal Donna Farmer que, hasta donde yo sé, venía de ser directora o subdirectora de varias organizaciones empresariales, pero admitía no tener la más remota idea sobre scrum o agilidad. Era evidente que esta decisión no había gustado a una parte importante de los miembros de la anterior junta directiva y a varios pilares de la comunidad scrum.

Por alguna razón que yo desconocía, muchas miradas se posaban en Tobias Mayer.

Había oído hablar de Tobias. Al fin y al cabo, Tobias llevaba involucrado en la comunidad desde hacía muchos años - siete más o menos - y había implementado scrum en algunas de las organizaciones pioneras como Yahoo!. Independientemente de los resultados de dichos experimentos y de lo mucho o poco que se parezcan a lo que cada uno considera ‘agilidad’ y ‘scrum’, había que darle crédito al tipo. Tobias también había participado en la junta gestora de la Scrum Alliance durante el año anterior.

Pero cuando uno oye hablar de Tobias es inevitable que determinados adjetivos salgan en la conversación. Radical. Anarquista. Utópico. Idealista. Si uno entabla dicha conversación en inglés, los términos no varían demasiado. Troublemaker.

Yo no lo sabía en aquel entonces, pero Tobias había renunciado a sus certificaciones y su estatus de la Scrum Alliance en verano de 2010 y, un mes antes del congreso de Amsterdam, había escrito un demoledor artículo contra la organización en su blog76 tildándola de dictadura centrada en los beneficios, de preocuparse más de su estatus que de ser creativos, de ser la encarnación de todo aquello que scrum intentaba eliminar en las organizaciones tradicionales.

Total, que Tobias no estaba nada contento con el curso que estaban tomando las cosas en la Scrum Alliance. Tengo grabada la imagen de la sesión plenaria en la que la junta directiva explicaba a todo el mundo las decisiones que habían tomado y, mientras tanto, Tobias estaba sentado en una esquina, cabizbajo, cejijunto y con la cabeza enterrada en su portátil, ignorando al resto de representantes.

Esta imagen, en aquel momento, no hizo sino reforzar mi convencimiento de que Tobias era un inadaptado.

Y qué iba a hacer… Pues lo asesiné.

La explicación de por qué digo que lo asesiné también surge en el Scrum Gathering de Amsterdam. Había por allí un Certified Scrum Trainer argentino, un tal Alan Cyment, del que evidentemente había oído hablar también. Sólo habían dos CST hispanoparlantes conocidos en aquel momento, Alan Cyment y Xavier Quesada - con la posible excepción de Mike Beedle, a quien también conocí en aquel evento y que también andaba medio liado en los juegos de poder de la junta directiva de la Scrum Alliance. A Xavier lo conocía de los primeros eventos de agilidad celebrados en España y de los que fui coorganizador y patrocinador. Pero de Alan solo había oído hablar. Y, al igual que ocurría con Tobias, era inevitable que determinados comentarios surgieran al hablar de Alan.

No usa diapositivas en los cursos… hace teatro… cuidado, que es de la escuela de Tobias Mayer… Anarquista… Inadaptado… Radical… Utópico… Idealista.

El caso es que la curiosidad me picó, y me uní a una de las sesiones de que Alan facilitó - una versión de su famoso juego basado en el “teatro de los oprimidos” de Augusto Boal. Me lo pasé bastante bien, y aprendí un par de cosas sobre mí mismo y mi relación con los demás. Pero lo mejor vino cuando Alan facilitó un superjuego con todo el evento (unas doscientas personas) a la vez. Incluimos varios minijuegos que yo conocía y otros que no, y de cada uno de ellos extrajimos una pequeña conclusión.

Uno de ellos me caló muy profundamente. Se trataba de un ejercicio en el que, durante un minuto, debes hablar del tema que más te gusta del mundo. Mientras tanto, tu interlocutor tiene que hacer todo lo posible para mostrar que no le importa ni lo más mínimo lo que le estás contando. Al cabo de un minuto, cambian los roles. Los resultados son demoledores: mucha gente no es capaz de acabar el minuto - hablando sobre el tema que más les apasiona en la vida - y en general la gente se siente fatal tratando de no escuchar a la persona que tienes delante.

Gracias a este ejercicio, uno se da cuenta de que no escuchar a alguien o, lo que es peor, demostrar activamente que no escuchas a alguien, es una agresión en toda regla. Casi como asesinarlo.

Y por eso digo que yo asesiné a Tobias Mayer. Proclamé una damnatio memoriae sobre su nombre y descarté cualquier cosa que viniera asociada a él como radical, inadaptada, utópica, anarquista. Muerto. Y no fui el único, claro. Un sector muy destacado de la agilidad a nivel internacional pronunció la misma sentencia de muerte.

Lo triste de todo es que Alan Cyment me había demostrado lo mucho que se podía aprender de esta perspectiva. Y, con todo, no me di cuenta de mi actitud hacia Tobias y me dejé llevar por mis prejuicios.

Durante los siguiente años, por otra razones que no vienen al caso, emprendí un camino personal de mejora y descubrimiento que me llevó, entre otras muchas cosas, a estudiar budismo, meditación, atención consciente, psicología cognitiva, neurociencia, ciencia del comportamiento y otras disciplinas humanísticas. Probablemente todo empezó con Lyssa Adkins y su “Coaching de Equipos Ágiles”, un libro que me abrió una dimensión humana de las empresas y los proyectos que yo, probablemente, había menospreciado y pasado un poco por alto en mi trabajo como consultor en gestión de proyectos. Pero, indudablemente, mi exposición a otras fuentes agilistas, incluido Alan Cyment, tuvieron mucho que ver con ello.

Por ello, cuando Tobias publicó este libro que tienes entre las manos, fui capaz de detectar mi rechazo inmediato basado en un prejuicio, y me obligué a comprarlo y leerlo como ejercicio de disciplina, ecuanimidad y escucha activa. Por dejarlo claro, me obligué a leer un libro con el que, estaba seguro, iba a estar en desacuerdo. Al fin y al cabo, nunca he dejado de quejarme de los “anarcosindicalistas” del teclado que quieren proclamar la república de los desarrolladores y expulsar la tiranía de los gerentes… y va Tobias y diseña una portada inspirada en la iconografía soviética - puños en alto, rayos del amanecer y actitud de victoria. Y la palabra “revolución” que no falte tampoco en la portada. Pues ya me contará, astuto lector, lo que opiné del libro antes siquiera de abrirlo.

Salvo que ya haya leído el libro, el lector solo puede llegar a imaginar mi propia sorpresa cuando, arrancada la lectura, me bebí el libro a tragos ansiosos intercalando numerosos “ajá”, “pues claro”, “lo que yo decía”, “toda la razón del mundo”, “zas, en toda la boca”, “ahí le ha dado”...

Probablemente la mayor diferencia entre Tobias y yo, salvando las distancias, es el tiempo que él lleva luchando en la trinchera de la agilidad. A cada año que pasa noto como me voy volviendo menos fundamentalista, menos dogmático, y me voy refugiando más y más en las personas, los valores, los equipos, los principios. Me llego a preguntar si los que empiezan ahora con scrum no me mirarán a mí y dirán las mismas cosas que se han dicho siempre de Tobias: Utópico. Idealista. Radical.

Hace unos años propuse lo que se ha convertido en una de mis señas de identidad y tarjetas de visita internacionales - el modelo de madurez del scrum master o, como se le conoce hoy en día, la “teoría de la mamá scrum”. Básicamente, lo que trato de explicar con dicho modelo es que los scrum master - o cualquier otra variante de coach ágil - varían, aprenden y evolucionan con el tiempo, y por tanto el scrum master primerizo y el que lleva una década de práctica apenas hablan el mismo idioma. El scrum master primerizo, o “nota del scrum” en mi modelo, habla de rotar el puesto de scrum master entre los miembros del equipo, de programar el 90% del tiempo y hacer de scrum master en el 10% restante, de convocar las reuniones y apuntar los impedimentos. Sin embargo, el scrum master veterano, o “sensei del scrum”, habla de no intervenir, de escuchar, de actuar de espejo para que el equipo pueda verse reflejado, de permitir que el propio equipo detecte los impedimentos y los elimine. Ambos perfiles no se entienden entre ellos; no están de acuerdo en cuál es la figura del scrum master y cuáles sus obligaciones, porque hablan desde dos puntos separados del continuo espacio-tiempo.

De la misma forma, creo que para abarcar todo lo que Tobias nos ofrece en este libro hay que haberse batido el cobre a base de bien en las trincheras de la agilidad durante una buena temporada. Quienes buscan un “scrum de caja negra”, una metodología para atar corto a los equipos y mantenerlos bien fiscalizados, pero que produzcan más y más rápido, probablemente se verán disgustados por las sugerencias de autoorganización, mejora continua, retrospectiva, reducción de la deuda técnica, conversaciones, colaboración, hacer menos, programación en parejas… Al fin y al cabo, cuando dos personas programan juntas, ¿no se queda un ordenador libre e improductivo? ¿No estamos reduciendo la productividad al 50%?...

Lamentablemente, me piden un epílogo y no un prólogo, por lo que poco puedo hacer ya para recomendar una mente abierta a la hora de abordar el libro.

¿Como cerrarlo, entonces?

Hay una frase del libro en la que me reconocí especialmente: “la misión de scrum es cambiar la forma en la que trabajamos. No se trata de un cambio de proceso, sino de un cambio de cultura”. En última instancia, lo que estamos intentando es modificar la cultura de las empresas. Y la cultura, hemos aprendido, es definida sobre todo por una serie de valores y comportamientos compartidos en la búsqueda de un propósito común, una “causa noble” que aglutina nuestra identidad como tribu.

Desde mi punto de vista, uno de los mayores impedimentos para la creación de culturas ágiles en las empresas es que, tal como adelantaba hace un par de párrafos, los equipos de desarrollo son tratados como “cajas negras”: alimentados con requisitos y fiscalizados en función del número de horas-hombre consumidas frente a líneas de código producidas. Entre otros males, esto ha desembocado en la existencia de dos conjuntos de valores separados en la empresa, la cultura del equipo, que solo existe en el interior de dicha “caja negra”, y la cultura del resto de la organización, especialmente de los gerentes intermedios, uno de los puntos de resonancia cultural más importantes de la empresa moderna - los gerentes senior están demasiado desconectados del día a día, y los trabajadores “de trinchera” rara vez logran influenciar suficientemente una cultura, mucho menos definirla o cambiarla.

Este conflicto de valores desemboca en culturas degeneradas y disfuncionales, algo que le será muy familiar a la inmensa mayoría de lectores de este libro. Al fin y al cabo, hay un sesgo estadístico: si has decidido leer este libro en lugar del éxito editorial del momento, por algo será. Cuando escribí mi primer libro, “Agile Management”, mi preocupación era esencialmente este conflicto de culturas entre la gerencia y los equipos, la barrera que los equipos se encuentran cuando intentan extender la agilidad más allá de las estrechas fronteras de su “caja negra”; y mi intención era, y es, hablar a los gerentes y mostrarles formas de incorporarse a esta nueva forma de concebir las organizaciones.

En definitiva, como epílogo, me queda una cierta espinita clavada al final de esta lectura: la impresión de que, ante este conflicto de culturas, el diagnóstico de Tobias y de muchos agilistas es de “opresión corporativa”, y la prescripción facultativa de “poder a los equipos”. Anarquía, panarquía, descentralización de las decisiones, redes de valor o el nombre que emplee su agilista favorito. Es cierto que en mi primer libro dije que este tipo de organización sin gerentes era utópica más allá de ciertos experimentos radicales y, sin embargo, en el último año cada vez aparecen más ejemplos de organizaciones que están cruzando la línea y definiendo entornos de trabajo basados única y exclusivamente en equipos autoorganizados sin capas gerenciales añadidas. Pero no menos cierto es que esos experimentos son aún estadísticamente insignificantes, y seguimos enfrentados a un universo de organizaciones gestionadas por un statu quo que se resiste a desaparecer.

Mi perspectiva, mi escuela de pensamiento, es que hay que trabajar con las gerencias de las empresas y, al igual que un “nota del scrum” no puede pasar de forma instantánea a “sensei del scrum”, las organizaciones deben atravesar determinados estadios de madurez antes de poder plantearse la “anarquía agilista” de la que tanto nos habla Tobias. Semco, uno de los ejemplos clásicos de gestión radicalmente distribuida, tardó años, décadas, en alcanzar dicho estado. Zappos sólo se está planteando la eliminación de los gerentes después de años y años de cuidar, alimentar y mantener su cultura corporativa. Valve lleva desarrollando su modelo plano desde 1996. Netflix, a pesar de fomentar la responsabilidad, la delegación y la autoorganización, sigue manteniendo estructuras gerenciales.

Por ello, y aunque no es exactamente lo que propone Tobias, considero que muchos de sus lectores se verán tentados de prescribir a las organizaciones tradicionales un enfoque de “de cero a anarquía ágil en una semana”, y estoy convencido de que el propio Tobias les diría que es una receta segura para el desastre. En muchos casos, incluso la simple visión de lo que puede llegar a ser la compañía en el futuro puede “levantar la liebre” para la mayoría silenciosa y los rezagados de la organización, que pueden ver scrum y la agilidad como una amenaza al statu quo antes de evaluar las ventajas que proporciona. Mi aproximación a la transformación de las organizaciones es más gradual. Más adaptativa. Menos radical. Menos idealista. Menos utópica.

Pero quién sabe. Tal vez dentro de unos años tenga que volver a decir “Tobias tenía razón”...

1 HIGHSMITH, Jim. No More Self-Organizing Teams. The Cutter Blog, 13 de septiembre de 2007

2 En español el término “acracia” representa tal vez el concepto que más se acerca a esta definición

3 SUTHERLAND, Jeff. Shock Therapy: Bootstrapping Hyperproductive Scrum, http://blog.jeffsutherland.com; SUTHERLAND, Jeff, DOWNEY, Scott y GRANVIK Björn. Shock Therapy: A Bootstrap for Hyper-Productive Scrum presentado en la conferencia Agile 2009

4 Juego de palabras con el que muchos en la comunidad, entre ellos Jeff Sutherland, se refieren de modo despectivo a las implementaciones de scrum que no cumplen con alguna parte del framework

5 En inglés esta noción es mucho más fuerte que en español, ya que se suele referir a los programadores directamente como “ingenieros de software”

6 SPOOL Jared. Agile Usability Yahoo Group, 10 de enero de 2006

7 La expresión “el elefante en la sala” en inglés se refiere a una verdad incómoda, que nadie quiere admitir por más obvia que sea. En español a veces se refiere a la popular historia de “las ropas nuevas del emperador” para expresar una idea similar.

8 LEVY Steven. Hackers: Heroes of the Computer Revolution. New York: Anchor Press/ Doubleday, 1984

9 Como se aclaró antes, en inglés el término “ingeniería” se está refiriendo directamente a la “programación” en este caso

10 En este ensayo me voy a referir casi en todo momento al modelo de desarrollo offshore, en el cual se busca mano de obra barata en países del tercer mundo, creando equipos dispersos, que suelen tener enormes dificultades para poder colaborar de forma productiva. Hay algunas excepciones en las cuales este modelo puede funcionar. Suele ocurrir cuando distintos individuos (generalmente muy experimentados) se encuentran distribuidos, pero viven en zonas horarias razonablemente cercanas (máximo 3 horas de diferencia) y usan prácticas como el trabajo de a pares remoto para asegurar una buena dosis de colaboración. He visto funcionar esta configuración, pero incluso en este modelo perdemos la verdadera dinámica de equipo, en la cual el todo es más que la suma de las partes. En la mayoría de los modelos distribuidos tendremos a lo sumo las distintas partes que, por más brillantes que sean, casi nunca lograrán la sinergia que puede lograr el todo.

Es importante dejar en claro que tener un equipo en el mismo espacio físico no logra automáticamente que sea un equipo ágil. Obviamente se requiere muchísimo más que la presencia. Estar en la misma habitación se puede entender simplemente como un primer paso muy recomendado.

11 1 Esta actitud se ve claramente en la invención del despectivo término “scrum-pero”, que significa “Estamos haciendo scrum, pero no hacemos la práctica X”

12 FICHNER Abby. Where Do the Testers Go In Agile? Hacker Chick (http://www.hackerchick.com), junio de 2009

13 CRISPIN Lisa, GREGORY Janet. Agile Testing: A Practical Guide for Testers and Agile Teams. Boston: Addison-Wesley Professional, 2009

14 Término acuñado por Augusto Boal como parte de su “Teatro del Oprimido”. El espectactor comienza viendo una obra, pero, mediante distintos mecanismos como el “Teatro Foro”, participa activamente, modificando su destino y el de sus pares

15 Este ensayo, tal vez más que cualquier otro, juega una y otra vez con palabras. Ruego al lector la mayor paciencia, comprensión y utilización de cualquier dosis de inglés que posea, para poder entender mejor la intención original de Tobias al redactarlo

16 “Touchy-feely” en el original

17 “Command-and-control” en el original

18 KNIBERG Henrik. Kanban vs. Scrum: Making the Best of Both. Toronto: InfoQ Mini-Books, 2009

19 COHN Mike. Agile Estimation and Planning. New Jersey: Prentice Hall, 2005

20 SUTHERLAND Jeff, JAKOBSEN Carsten Ruseng Jakobsen y JOHNSON Kent. Scrum and CMMI Level 5: The Magic Potion for Code Warriors, presentado en la conferencia Agile 2007

21 El término “salto de paradigma” fue acuñado por Thomas Kuhn en 1962 en su libro La Estructura de las Revoluciones Científicas. Kuhn propone que el avance de la ciencia no es evolutivo, sino que se produce como “una serie de pacíficos interludios interrumpidos por revoluciones intelectualmente violentas durante la cuales “una mirada conceptual del mundo reemplaza a otra”. Kuhn defiende firmemente la idea de que una vez el nuevo paradigma se ha establecido, no hay lugar alguno en el mundo para aquel que ha sido reemplazado. KUHN Thomas S. The Structure of Scientific Revolutions. Chicago: University of Chicago Press, 1962

22 MILLER John H. Miller, PAGE Scott. Complex Adaptive Systems: An Introduction to Computational Models of Social Life. New Jersey: Princeton University Press, 2007

23 PASCALE Richard, MILLEMAN Mark y GIOJA Linda. Surfing the Edge of Chaos: The Laws of Nature and the New Laws of Business. New York: Crown Business, 2001

24 http://www.plexusinstitute.org

25 “The Plexus Story,” plexusinstitute.org

26 SCHWABER Ken, BEEDLE Mike. Agile Software Development with Scrum. New Jersey: Prentice Hall, 2001

27 SCHWABER Ken. Agile Project Management with Scrum. Redmond, Washington: Microsoft Press, 2004

28 Este ensayo fue escrito en 2007, pero las cosas han cambiado. Hoy en día se considera a estas prácticas dentro de la visión más difundida y aceptada del framework. Por ejemplo, los product owners son vistos como parte del equipo, los sprints suelen durar entre 1 y 2 semanas, se considera un desperdicio medir las tareas en horas y los tableros físicos han reemplazado a las hojas de cálculo en muchas organizaciones. Queda un largo camino por recorrer de todos modos, considerando que todavía existe un gran número de practicantes que todavía se aferran al primer scrum. Evidentemente algunos necesitan un proceso enteramente prescriptivo.

29 P. Ej. Este comentario de Dave Barrett enviado a la lista de discusión scrumdevelopment en febrero de 2007: “Considero que el libro [Agile Software Development with Scrum] se encuentra tan vigente como cuando Ken lo escribió. Todavía utilizamos sprints de 30 días, planillas Excel para los gráficos de burndown, realizamos el seguimiento en horas y estimamos en Días Ideales de Desarrollo. Y funciona muy bien, gracias. Creo entender por qué hay gente que siente la necesidad de ornamentar scrum: es demasiado simple. No obstante, no requiere ornamentación, sino que mantenerse enfocado en los fundamentos es la clave para del éxito”.

30 KERIEVSKY Joshua. Stop Using Story Points. Industrial Logic (http://www.industriallogic.com/blog), 12 de octubre de 2012

31 COHN Mike. Agile Estimation and Planning. New Jersey: Prentice Hall, 2005

32 BOAL Augusto. Teatro del Oprimido. Barcelona: Alba Editorial, 2009

33 HEUSSER Matt, McMAHON Chris. Performing the Software. ST&P Magazine, volumen 6, número 10, octubre de 2009

34 http://agileatlas.org/atlas/scrum

35 COCKBURN, Alistair. Agile software development : the cooperative game. Upper Saddle River, New Jersey: Addison-Wesley, 2007

36 Recientemente discutí esto con Alistair, pero no llegamos a ningún punto de vista común. Voy a seguir intentándolo.

37 SCHWABER Ken. ScrumBut. http://scrum.org/ScrumBut

38 OWEN, Harrison. Open space technology a user’s guide. San Francisco: Berrett-Koehler Publishers, 2008

39 El uso del término “holgazanear” equivale al término “slack” según lo define DEMARCO en su libro Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. New York: Crown Business, 2002

40 HUMPHREY Doris. The Art of Making Dances. New York: Grove Press, 1959

41 KERTH Norman. Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House, 2001

42 SUTHERLAND Jeff. Agile Development: Lessons Learned From The First Scrum. http://scrumalliance.org/resources/35, octubre de 2004

43 Podría traducirse como “El quehacer artístico”, pero hemos preferido mantener el nombre original

44 AUSTIN Rob, DEVIN Lee. Artful Making: What Managers Need to Know About How Artists Work. New Jersey: Financial Times Prentice Hall, 2003

45 IVERY Michael. Scrum Users Yahoo Group, 19 de noviembre de 2005

46 Definición del diccionario de la Real Academia para “melé”, su equivalente en español

47 BROWN Susan. The Politics of Individualism: Liberalism, Liberal Feminism and Anarchism. Montréal: Black Rose Books, 2002

48 DE CLEYRE Voltairine. Selected works of Voltairine de Cleyre. New York : Mother Earth Pub. Association, 1914

49 ROCKER Rudolf. Anarcho-Syndicalism. London: Pluto Press, 1989

50 CHRISTOPHER Bill, ROBINSON Jack, SANSOM Philip Sansom y TURNER Peter. The Relevance of Anarchism en The State Is Your Enemy: Selections From Freedom 1965-86. Londres: Freedom Press, 1991

51 ROCKER Rudolf. The London Years. Londres: Robert Anscombe & Co. Ltd, 1956

52 TAYLOR Frederick Winslow. The Principles of Scientific Management. New York: Harper & Brothers, 1911

53 FREIRE Paulo. Pedagogía del oprimido. Madrid: Siglo Veintiuno de España, 1975

54 ORWELL George. Rebelión en la Granja. Barcelona, Destino, 2006

55 Florynce Kennedy (1916-2000) fue la primer mujer negra en graduarse en la Facultad de Derecho de Columbia. Fue activista social, feminista, cofundadora de la National Organization for Women y fundadora de la National Black Feminist Organization

56 Correspondencia personal

57 En español no existe una traducción directa de ambos términos, pero es interesante notar que Tobias hace una distinción entre los términos “continuous improvement” y “continual improvement”. El primero implica que cada cambio es una mejora, por lo que la mejora ocurrirá permanentemente, cosa que no suele suceder. Algunos cambios nos hacen retroceder, incluso generar fallos. Lo que importa aquí es ver una tendencia hacia la mejora, por lo que preferimos el uso del segundo término, que permite eventuales contratiempos, sin que eso represente una desgracia irremontable.

58 http://liquidfeedback.org

59 Q & A Roundabouts. IIHS (http://iihs.org/research/qanda/roundabouts.aspx)

60 CAPUZZO Jill. A Shift, but for Some Drivers, a Vicious Circle. New York Times, 25 de noviembre de 2007

61 KEH Andrew. European Import Has Cars Spinning. Heads, Too. New York Times, 18 de noviembre de 2010

62 Q & A Roundabouts. IIHS (http://iihs.org/research/qanda/roundabouts.aspx)

63 MERTON Thomas. El Camino de Chuang Tzu. Buenos Aires, Lumen, 1996

64 Narcotics Anonymous, World Service Office, 1984

65 Quisiera aclarar que estoy utilizando scrum como un mero ejemplo de lo que sería un enfoque radicalmente distinto al mundo del trabajo. En un sentido más amplio de la cuestión, me estoy refiriendo a un enfoque empírico, autoorganizado y colaborativo, con jerarquías aplanadas y trabajadores autónomos, que tanto intimida a los tradicionalistas.

66 WEINBERG Gerald. Quality Software Management: Vol. 1 Systems Thinking. New York: Dorset House Publishing, 1992

67 La noción de “tiempo vivo” es una traducción libre que hice del término “slack time” según la definición en DEMARCO Tom. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. New York: Crown Business, 2002

68 FOWLER Martin. Why Scaling Agile Is the Last Thing You Want to Do. Sesión principal en el 1st Canadian Agile Network Workshop, Banff, Alberta, Canada, febrero de 2003

69 AA World Services. The 12 Traditions of Alcoholics Anonymous. New York, 1946

70 La palabra deadline, traducida muchas veces como “fecha límite”, permite un interesante juego de palabras en el original con la posibilidad certera de muerte

71 ENDENBU Gerard. Sociocracy: The organization of decision-making. Delft: Eburon, 1998

72 KINGSOLVER Barbara. La Biblia Envenenada. Barcelona: Del Bronce 2000

73 Esta proporción varía entre 80/20 y 95/5 dependiendo de la fuente. El punto sigue siendo el mismo: los problemas de la organización se encuentran notablemente en el sistema.

74 MARSHALL Bob. Think Different (http://flowchainsensei.wordpress.com)

75 https://vimeo.com/16901077

76 http://agileanarchy.wordpress.com/2010/10/12/the-scrum-compliance/

Contenidos

La introducción de Tobias

La introducción de Alan

La gente: Aquellos exploradores intrépidos

Otra forma de pensar

El corazón de scrum

Autoorganización y anarquía

¿Terapia de shock o compasión?

Artesanos del software

Los equipos distribuidos no son equipos

El Hombre Araña dice que...

Desenterrando impedimentos haciendo incluso menos

¿Test(osterona)?

Pagando la deuda técnica

El explorador ágil

La emotividad sincera es el nuevo hardcore

Un scrum popular

Proceso: El Sendero Escarpado

Scrum: Un lugar en el mundo

¿Cuándo deja scrum de ser scrum?

Adición y sustracción en scrum

Estimación

Estimación I: Tamaño

Estimación II: Tiempo

Estimación III: No estimarás

Los roles en scrum: una abstracción

Scrum no hace nada

Matrimonio, pero

No tengas reuniones

Timebox != Compromiso

Retrospectiva ya

El alma de scrum

Cultura: La tierra prometida

Cambio organizacional catastrófico

Anarquía ágil

Cabalgando dinosaurios

Opresión corporativa

Amebas organizacionales

Yendo en círculos

La cuchilla del agente de cambio es delgada y filosa

Adopción de scrum: el despertar

Cultura de equipo o cultura de proyecto

Los equipos no se construyen

Escalando scrum: la perspectiva del alcohólico

Buscando consentimiento

El espíritu del cambio

Apéndice I: Scrum

Apéndice II: Cómo contratar un consultor ágil

Epílogo

Sobre Les Autores

Tobias Mayer

Inglés de nacimiento y californiano por adopción, Tobias Mayer ha pasado tanto por el mundo del desarrollo de software como por el del counseling comunitario, el teatro técnico y el mundo editorial. Su experiencia ecléctica ha tenido una gran influencia en su participación en el mundo de la agilidad. Actualmente trabaja como coach interno y consultor en Yahoo!

Alan Cyment

Originalmente programador obsesionado con la simpleza del código y la satisfacción del usuario, devoto del psicoanálisis y la actuación, Alan Cyment se inició en scrum luego de traer a Tobias a dictar un curso a su Buenos Aires natal en 2006. Se convirtió en el primer Certified Scrum Trainer por la Scrum Alliance en 2008 y hoy en día es un referente de la agilidad en el mundo de habla hispana. Actualmente es coach y formador en Agilar.