Nuevo
Resumen del libro
Por: Jeff Sutherland
La metodología de desarrollo ágil de proyectos que está revolucionando el mundo
Introducción
Hace más de veinte años Ken Schwaber y yo inventamos Scrum con el objetivo de encontrar una forma más eficaz de crear software. Hasta aquel momento, la mayoría de las empresas usaba el método en cascada, en el que el trabajo se completa por fases y se avanza paso a paso hasta el lanzamiento del producto. Este proceso era lento, impredecible y a menudo el resultado era un producto que nadie quería o por el que nadie estaba dispuesto a pagar.
Lo normal en la planificación con diagramas de Gantt es no cumplir los plazos y pasarse del presupuesto de forma desastrosa. Para evitar esto, en 1993 inventé una forma nueva de hacer las cosas: Scrum, un método que está en línea con los sistemas evolutivos, adaptativos y que se autocorrigen. Este método ha sido adoptado por la industria tecnológica, pero sigue siendo relativamente desconocido en otros campos. Ese fue el motivo de que escribiera este libro, revelar y explicar el sistema Scrum a empresas fuera del ámbito de la tecnología.
En las páginas que siguen, descubrirá que hemos utilizado el Scrum para hacer de todo, desde automóviles asequibles de bajo consumo a la actualización del sistema de datos del FBI. Este libro le ayudará a entender cómo el Scrum puede ayudarle a transformar el funcionamiento de su compañía y su forma de crear, planificar y pensar, del mismo modo que ha revolucionado la innovación y el tiempo de lanzamiento al mercado en un número grandísimo de empresas nuevas y en cantidad de productos que proceden de Silicon Valley y del mundo de la tecnología.
Los orígenes del Scrum: lo que ya no vale
En 2009 Jeff Johnson, antiguo subdirector de Ingeniería de Tecnologías de Información de Lehman Brothers, aceptó un trabajo en el FBI. Tenía que crear un nuevo sistema informático para la institución adaptado al siglo XXI tras varios años de fracasos y millones de dólares del contribuyente dilapidados. Después de los atentados del 11 de septiembre de 2001, la Comisión del Congreso de EE. UU. había constatado que en el FBI no existía un mecanismo eficaz para recuperar o compartir los conocimientos adquiridos durante años. Sin embargo, los sucesivos y costosos planes que se habían puesto en marcha habían fallado.
La razón era que el método en cascada y los diagramas de Gantt, que señalan las distintas fases de un proyecto divididas en etapas de descubrimiento, diseño, desarrollo y comprobación, eran poco realistas. Los plazos no se cumplían y los objetivos no se lograban.
En los diagramas de Gantt, todos y cada uno de los pasos de un proyecto se representan en detalle. Cada hito. Cada fecha de entrega. Contemplar estos gráficos es impresionante. He visitado muchísimas empresas en las que el único trabajo de algunas personas consiste en actualizar ese diagrama de Gantt todos los días. El único problema de este sistema es que siempre, siempre, falla. Cuando estos planes elegantemente diseñados se encuentran con la realidad, se vienen abajo. Pero en lugar de desechar el plan o la forma de pensar en el plan, los gerentes contratan a personas para que parezca que funciona. Básicamente, contratan a gente para que les mienta.
Jeff Johnson y su jefe, Chad Fulgham, adoptaron el sistema Scrum, creado por mí y aplicado por primera vez al desarrollo de software. La mayor ventaja del Scrum frente al método de planificación en cascada es que se basa en la forma en que la gente trabaja, no en cómo dice que trabaja. El Scrum cuestiona por qué lleva tanto tiempo y tantos esfuerzos hacer las cosas, y por qué lo hacemos tan mal a la hora de imaginar cuánto tiempo y esfuerzo requieren. Tratar de reducir la conducta humana a diagramas y gráficos codificados por colores es absurdo y supone un esfuerzo condenado al fracaso.
Básicamente, el Scrum se basa en una idea sencilla: cada vez que iniciamos un proyecto, ¿por qué no comprobamos cómo va cada cierto tiempo, vemos si lo que estamos haciendo apunta en la buena dirección y si es lo que la gente realmente quiere? ¿Y por qué no comprobar si existen maneras de mejorar lo que estamos haciendo, de hacerlo mejor y más rápido, y qué es lo que puede estar impidiendo que sea así? Esto es lo que se denomina un ciclo de “inspección y adaptación”. Cada poco tiempo, dejamos de hacer lo que estamos haciendo, revisamos lo que hemos hecho y vemos si sigue siendo lo que deberíamos estar haciendo y cómo podríamos mejorar. Es una idea sencilla, pero ejecutarla requiere reflexión, introspección, sinceridad y disciplina.
En el FBI, el primer problema del nuevo equipo fueron los contratos externos, que habían consumido millones de dólares sin haber conseguido el tan deseado sistema de información moderno. Jeff Johnson y Chad Fulgham internalizaron el desarrollo de la programación y redujeron el personal de varios cientos a menos de cincuenta personas. Imprimieron toda la documentación sobre los requisitos que debería tener el nuevo sistema y establecieron prioridades. A menudo, la gente dice que todo es importante y ya está. Pero en la programación de software existe una regla, nacida tras décadas de investigación: el 80 % del valor de cualquier producto de software no reside más que en el 20 % de sus características.
Jeff Johnson y su equipo no sabían exactamente cuánto tardarían en concluir el proyecto. Algo que yo siempre les digo a los directivos es que sabré la fecha cuando vea cómo mejoran los equipos, lo rápido que pueden ir y lo que pueden llegar a acelerar. Y esto es lo que hizo Johnson al establecer ciclos de trabajo de dos semanas. Al final de cada ciclo se producía una mejora del producto final, algo que funcionaba y se podía mostrar a los usuarios. Esto es lo que en Scrum denominamos sprints. Johnson usó estos sprints para medir la velocidad de los equipos y su capacidad de mejora y averiguar qué impedimentos los retrasaban. A los tres meses de trabajar de esta manera, Johnson ya tenía una idea bastante aproximada de cuándo podría tener completado todo el proyecto.
El proyecto Sentinel, puesto en marcha en julio de 2012, necesitó 18 meses de codificación y otros dos para implementarlo en todo el FBI. Fue una tremenda presión de tiempo porque hay que tener en cuenta que este sistema se emplea prácticamente para todo: para pagar a los informantes del FBI, almacenar pruebas, organizar los expedientes de los casos, registrar reuniones... Años de trabajo perdido e ingentes cantidades de dinero habían instalado el escepticismo entre los responsables y usuarios del FBI. Pero el método Scrum logró vencer todas las reticencias y acabó con el mito de que un proyecto complejo necesita una fortuna y décadas para desarrollarse.
El efecto de Sentinel en el FBI ha sido espectacular. La capacidad de comunicar y compartir información ha cambiado de forma radical lo que el FBI es capaz de hacer. En enero de 2013, una oficina del FBI recibió el aviso de que una cuenta de una pequeña empresa había sido pirateada. Se había transferido un millón de dólares a otro país antes de que los bancos de EE. UU. pudieran detener la operación. Gracias a Sentinel, el oficial del FBI se coordinó con el agregado jurídico de la embajada en el país de destino, que alertó a las autoridades locales, que a su vez interceptaron la transferencia antes de que llegara al sistema bancario. Todo esto ocurrió en cuestión de horas, lo que sencillamente no podría haber sucedido en la época (no tan lejana, aunque se crea lo contrario) de las tres copias de papel y los bolígrafos rojos para señalar lo importante en un expediente…
En una entrevista, Johnson contó que lo más impactante del Scrum eran las demos, que le permitieron avanzar con regularidad hacia un producto demostrable. El Scrum, basado en la generación de versiones operativas del producto en ciclos cortos, facilita el feedback temprano y la eliminación de errores y esfuerzos baldíos. El Scrum no va dirigido a los programadores, sino a los clientes y a todas las partes implicadas.
Los miembros del equipo original siguen en sus puestos, realizando mejoras y añadiendo nuevas funcionalidades al sistema que construyeron.
¿Qué me llevó a crear el Scrum? Tras la guerra de Vietnam, cursé un máster en Estadística en la Universidad de Stanford y me hice profesor de Matemáticas en la Academia de las Fuerzas Armadas. Allí inicié mi doctorado en Biometría y mi director de tesis me retó a explicar las variaciones entre los tipos de tumores. Durante casi una década aprendí mucho sobre teoría de sistemas y también sobre adaptación. Años después, se me ocurrió que, al igual que las células, las organizaciones, equipos y personas son sistemas complejos adaptativos.
En 1983, la empresa MidContinent Computer Services me contrató para trabajar en las redes de cajeros automáticos. Como se producían retrasos crónicos y los proyectos solían sobrepasar el presupuesto asignado, conseguí formar una organización separada formada por todos aquellos implicados en la red de cajeros automáticos. Allí puse en práctica algunos elementos de lo que luego sería el Scrum, como responsables de producto (Product Owners), lista de objetivos o requisitos pendientes (Product Backlog) y sprints semanales. En seis meses nos convertimos en el departamento más rentable de la empresa.
Convencido de que el constante feedback era la mejor forma de aumentar el rendimiento, en 1993 llevé mis nuevas ideas a una empresa llamada Easel. Mi objetivo era desarrollar una línea nueva de productos que permitieran a nuestros clientes diseñar y construir aplicaciones internas. Mi equipo y yo pasamos semanas leyendo publicaciones sobre organización de equipos y desarrollo de productos hasta que encontramos un artículo de 1986 de la Harvard Business Review escrito por los catedráticos japoneses Hirotaka Takeuchi e Ikujiro Nonaka.
En este texto, titulado The New Product Development Game (‘El nuevo juego del desarrollo de producto’), sus autores afirmaban que el sistema en cascada tenía fallos importantes y que las empresas que triunfaban lo hacían porque utilizaban un proceso de desarrollo simultáneo, rápido y flexible. Los equipos eran multidisciplinares; tenían autonomía; los directivos no daban órdenes sino que actuaban como facilitadores apartando los obstáculos del camino de sus equipos; y tenían un propósito trascendente, es decir, aspiraban a algo más allá de sí mismos. Los catedráticos comparaban el trabajo de estos equipos con el rugby y decían que los mejores actuaban como si estuvieran en una Scrum o melé: “la pelota se la pasan los unos a los otros en el equipo, mientras avanzan como una unidad en el campo”.
Aquel fue el nacimiento el Scrum. El producto fue entregado en Easel en el plazo contemplado de seis meses sin desviaciones presupuestarias y con menos fallos que cualquier entrega anterior. Me entusiasmé tanto con las posibilidades de esta nueva forma de gestión de proyectos que todo mi trabajo futuro se centró en perfeccionar el Scrum. Dos años después, en el marco de un congreso de la Association for Computing Machinery presenté un artículo escrito junto a Ken Schwaber titulado “SCRUM Development Process” (‘El proceso de desarrollo del SCRUM’) en el que codificábamos estas prácticas con el objetivo de crear grupos hiperproductivos guiados por el principio PDCA (Plan, Do, Check, Act), o Planificar, Hacer, Comprobar y Actuar.
El PDCA se basa en las técnicas de fabricación japonesa, que a su vez se deben a la labor del estadounidense W. Edwards Deming, quien trabajó en aquel país durante la ocupación militar tras la Segunda Guerra Mundial. La influencia de Deming en la fabricación japonesa fue espectacular. Formó a cientos de ingenieros en lo que se denomina “control estadístico de procesos”. La idea básica es medir exactamente lo que se está haciendo y en qué medida se está haciendo bien, y esforzarse por una “mejora continua” (kaizen). No hay que mejorar solo una vez; hay que mejorar constantemente. Siempre hay que estar buscando algo que mejorar. Nunca jamás conformarse con lo que se ha logrado.
El ciclo PDCA es lo que permitió que empresas como Toyota se convirtieran en líderes mundiales. En Japón, el Scrum no se ve como una moda, sino como una forma de vida. Práctica, atención y esfuerzo continuado para que las cosas fluyan y ocurran. Ese es el objetivo final del Scrum, un método que nos permite alcanzar un propósito más alto con alegría y coordinación. Veamos cómo conseguirlo.
Cómo usar el Scrum
1.- Equipos. Los equipos son los que hacen que gire el mundo. En ellos se basa el Scrum, aunque en el sector empresarial a menudo nos centramos exclusivamente en los individuos, porque, claro, ¿quién no quiere tener a los “mejores” en su organización? Pero si estudiamos a los equipos, descubrimos que las diferencias de rendimiento entre distintos grupos de personas pueden ser descomunales.
En el primer artículo en el que se explicaba lo que luego se convertiría en el Scrum, Takeuchi y Nonaka decían que los mejores equipos son trascendentes, esto es, tienen un sentido del propósito más allá de lo normal. En un sentido muy real, la propia decisión de no ser uno más, sino de ser grandes, cambia la forma en que se ven a sí mismos y de lo que son capaces.
Los mejores equipos también son autónomos. Uno de los conceptos clave del Scrum es que los miembros del equipo deciden por sí mismos cómo van a trabajar. La responsabilidad de establecer los objetivos estratégicos es de la dirección, pero es el equipo el que decide cómo alcanzar dichos objetivos.
El tercer puntal de un buen equipo es que en su interior existan todas las capacidades necesarias para hacer las cosas, es decir, que sean multidisciplinares. Evitar la separación de roles para que cada equipo cuente con todas las personas para hacer lo que tiene encomendado de principio a fin es la receta básica del Scrum. Hay que buscar diversidad de capacidades, pensamiento y experiencia. Un especialista no debe identificarse por su especialidad, sino por el producto en el que está trabajando.
Así es como funcionan, por ejemplo, las Fuerzas de Operaciones Especiales (SOF) de EE. UU. En ellas, cada equipo cuenta con todas las capacidades para desempeñar su misión de principio a fin. Y reciben una formación multidisciplinar. Hay que tener la seguridad de que, si en una operación matan al médico del equipo, el especialista en comunicaciones, por ejemplo, puede apañárselas para curar a un compañero herido en combate.
Otra característica de las Fuerzas Especiales es que, a diferencia de un ejército “normal”, no existe separación entre la recopilación de información y la planificación de operaciones. No hay que transferir las cosas de un equipo a otro, con el consiguiente riesgo de errores. De modo que existe una comunicación constante entre las personas que reúnen la información, los que planifican qué hacer con ella y los que salen a ejecutar las misiones.
Por el hecho de que la variedad pueda lograr grandes resultados, no tenemos que emular a Noé y formar un equipo con una pareja de cada especie. El tamaño ideal de un equipo sería entre cinco y nueve personas, aunque yo he visto equipos más pequeños, incluso de tres personas, que funcionan a un nivel muy alto. Pero si cuentan con más de nueve miembros, su velocidad se reduce. Esta es la llamada ley de Brooks, formulada por Fred Brooks en 1975 en su libro El Mítico Hombre-mes. Expresado en términos sencillos, esta ley postula que “añadir personal a un proyecto que va retrasado lo retrasa todavía más”. Esto ha quedado demostrado en un estudio detrás de otro.
Una de las razones obvias es que si incorporamos a una persona nueva al proyecto tarda un tiempo en adaptarse y empezar a ser productivo. Esto, a su vez, hace que el resto de integrantes reduzca también su velocidad de trabajo. Además, si un equipo crece demasiado, la capacidad de cada persona para comunicarse con claridad con los demás se reduce. Y, con frecuencia, el equipo se descompone social y funcionalmente en subequipos que están trabajando para lograr objetivos diferentes.
Una última reflexión sobre los equipos: culpar a los individuos es un error y no sirve de nada. No hay que buscar a las personas que lo hacen mal; hay que buscar y cambiar los sistemas mal diseñados, aquellos que generan incentivos que traen consigo la mala conducta y premian el bajo rendimiento.
2.- Tiempo. El tiempo es el limitador inapelable de la conducta humana. Cuando hay mucho trabajo por delante, el mensaje para la gente es que hay que sentarse, remangarse y echar horas. Pero a los seres humanos no les va nada bien trabajar así. Somos un desastre a la hora de concentrarnos, pasamos más tiempo del necesario en la oficina, y nunca estimamos bien cuánto tiempo nos llevarán las cosas.
Aunque no podemos hacer que el sol se pare, sí es posible hacer que corra más. ¿Cómo? Aplicando el sprint, una idea que comencé a poner en práctica en la empresa Easel en 1993. La idea era que mi equipo y yo nos volcaríamos en algo durante un breve periodo de tiempo y luego nos pararíamos a analizar lo que habíamos conseguido.
Cuando puse en marcha el primer Scrum en Easel, le dije al director general que no iba a enseñarle la evolución de un absurdo e interminable diagrama de Gantt. Le prometí que cada mes podría ver una parte del software que construíamos en funcionamiento. No algo que les sirviera solo a los programadores. No una obra arquitectónica maestra. Una pieza de software que el cliente pudiera usar en la vida real. Una característica totalmente implementada. Y todo gracias a los sprints. Los llamamos así porque la palabra evocaba una cierta intensidad.
Los sprints son lo que a menudo se llaman “cajas de tiempo”. Son siempre de la misma duración y establecen un ritmo de trabajo en el que las personas saben cuánto trabajo pueden tener hecho en un periodo determinado de tiempo. En muchos de los centros de trabajo donde se utiliza el Scrum se puede encontrar un elemento común: notas autoadhesivas pegadas en una pizarra que tiene tres columnas: pendiente (backlog), en proceso (in progress) y hecho (done). En la columna de pendiente están todas las tareas que el equipo cree que podrá completar mientras dure el sprint. Nada pasa a la columna de hecho a menos que pueda ser utilizado por el cliente. Con este sistema cada miembro del equipo puede ver en qué están trabajando los demás en todo momento.
Un elemento crucial del sprint es que, una vez que el equipo se compromete con lo que tiene que conseguir, el cupo de tareas queda cerrado. Nadie fuera del equipo puede añadir nada más. Interferir y distraer al equipo reduce la velocidad drásticamente.
En mi caso, yo comencé con sprints de cuatro semanas, pero después nos dimos cuenta de que no estábamos yendo bastante rápido, que podíamos hacer más. Así nació la reunión diaria, en la que el Scrum Master, la persona a cargo de dirigir el proceso, formula a cada miembro del equipo tres preguntas:
-
¿Qué hiciste ayer para ayudar al equipo a terminar el sprint?
-
¿Qué vas a hacer mañana para ayudar al equipo a terminar el sprint?
-
¿Qué obstáculos se interponen en el camino del equipo?
Si la reunión dura más de quince minutos es que estamos haciéndolo mal. La utilidad de estas reuniones diarias radica en que el equipo sepa siempre en qué punto del sprint se encuentra y que no se produzcan embotellamientos ni acaparamientos de información. A este respecto, es importante señalar que diversos estudios han demostrado que cuanta más información, cuantas más personas saben más cosas, más rápido es el equipo.
Como el mayor enemigo de la saturación es la especialización y la proliferación de roles y títulos dentro del grupo, en Easel nos deshicimos de todos. Así es como estas reuniones diarias, celebradas siempre a la misma hora, en las que todo el mundo estaba de pie, y a la que tenían que asistir todos, funcionaron, porque no se plantearon como una rendición de cuentas individual, sino como un intercambio rápido de opiniones para avanzar rápidamente hacia la victoria, es decir, completar el sprint.
Yo quiero equipos agresivos, equipos que salgan de la reunión diaria sabiendo qué es lo más importante que deben conseguir ese día. Que si una persona oye a otro decir que una tarea les va a llevar un día, es posible que otra sepa cómo hacerlo en una hora si trabajan juntos. El equipo debe querer ser el mejor.
De esta forma, el Scrum altera la idea que tenemos del tiempo. En vez de verlo como algo lineal, terminamos considerándolo como algo cíclico. Cada sprint es una oportunidad para hacer algo totalmente nuevo; cada día, una oportunidad de mejorar. Pensemos en muchos de los proyectos que hacemos. Apuesto a que rara vez recibimos feedback sobre ellos hasta que están acabados, y esto puede ser después de meses, incluso años. Podemos estar yendo en la dirección completamente equivocada durante meses y no sospecharlo siquiera. Dejemos de desperdiciar el tiempo.
3.- Desperdiciar es delito. Cuando voy a una empresa, suelo encontrarme un desperdicio del 85 % del esfuerzo. Solo una sexta parte del trabajo produce algún valor. Según Taiichi Ohno, el padre de Toyota y autor de Toyota Production System, una de las fuentes principales de inspiración del Scrum, “el desperdicio es un delito contra la sociedad más que una pérdida de negocio”.
Muchas ofertas de trabajo actuales exigen “ser capaz de llevar cinco proyectos a la vez”. La idea de la multitarea resulta atractiva, pero no estamos tan capacitados para ello como creemos. El psicólogo David Sanbonmatsu realizó un estudio cuya conclusión fue que “las personas no abordan varias tareas a la vez porque sean buenas en eso. Lo hacen porque son más distraídas, no pueden concentrarse. Les resulta difícil inhibir el impulso de hacer otra actividad”.
En mis cursos de formación siempre propongo a mis alumnos un pequeño ejercicio. Es sencillo, pero demuestra hasta qué punto la multitarea le resulta difícil al cerebro y supone un desperdicio de tiempo. La tarea consiste en escribir los números del 1 al 10, los números romanos del 1 al 10 (I, II, III, etc.) y las letras de la A a la L. La primera vez hay que escribir una columna con todos los números arábigos, después todos los romanos en otra columna y, finalmente, las letras. La segunda vez hay que hacerlo por filas, es decir, primero hay que escribir 1 I A, luego 2 II B, y así sucesivamente. Haga la prueba y cronométrese. En mi caso, la primera tarea (sin cambio de contexto) la hago siempre en la mitad de tiempo que la segunda (multitarea).
En una de las obras clásicas sobre desarrollo de software informático, Quality Software Management, Gerald Weinberg afirma que tres proyectos simultáneos ocasionan una pérdida del 40 % por cambios de contexto. En el caso de cinco proyectos, las pérdidas alcanzan nada menos que el 75 %.
En el Scrum, existe un ritmo de trabajo y en cada interacción o sprint el equipo trata de tener hechas varias cosas. Pero “hechas” implica un producto acabado, final, que pueda ser utilizado por un cliente. Si algo está a medio hacer al final del sprint, estaremos peor que si no hubiéramos empezado a hacerlo. Habremos gastado recursos, esfuerzos y tiempo (seguramente a causa de la multitarea), y no tendremos ningún producto final. Habría sido mejor crear algo más pequeño, algo que realmente funcionara.
No siempre hacemos las cosas bien a la primera. Cuanto más se tarda en realizar comprobaciones, más se tarda en subsanar los errores por la sencilla razón de que solo podemos concentrarnos en una cosa cada vez. No arreglar las cosas en el momento puede costarnos muy caro. El doctor James Womack, fundador del Lean Enterprise Institute del MIT, estudió la fabricación de coches y descubrió que los alemanes tardaban más tiempo en arreglar un coche que los japoneses en fabricarlo. La razón era sencilla: en las fábricas de Toyota cualquier trabajador podía parar la línea de producción si detectaba un error. Arreglaban un problema una vez y quedaba solucionado para siempre. Si no lo hacían, ese mismo defecto podría repetirse en cientos de vehículos. En las fábricas europeas, por el contrario, había docenas de personas al final de la línea dedicadas a arreglar problemas, sin comunicación con los operarios que fabricaban el automóvil. La diferencia era abismal.
Cuando estamos trabajando en un proyecto, creamos todo un espacio mental a su alrededor. Sabemos todas las diferentes razones por las que hacemos algo. Tenemos que mantener una estructura bastante complicada en la cabeza. Recrear esa construcción una semana más tarde es difícil. Tenemos que recordar todos los factores que estábamos considerando cuando tomamos esa decisión. Tenemos que convertirnos de nuevo en nuestro pasado, volvernos a colocar en una situación mental que ya no existe. Hacer esto lleva tiempo. Mucho tiempo. Según muchos estudios, veinticuatro veces más de lo que llevaría si corrigiéramos el problema nada más descubrirlo.
Por otra parte, la productividad también depende de las horas de trabajo, pero más allá de un límite la productividad cae en picado. Según el empresario y consultor Scott Maxwell, el Scrum no solo es siempre más productivo que el sistema en cascada, sino que además su pico de productividad se consigue con menos horas de trabajo, no más de cuarenta a la semana. A más horas de trabajo, más errores y más esfuerzo empleado para corregir que para crear. El agotamiento disminuye nuestra capacidad de autocontrol, concentración, disciplina, reflexión y clarividencia.
Objetivos imposibles, esfuerzos aparentemente heroicos que en realidad son fallos de planificación, las normas estúpidas y los idiotas, esas personas que inspiran temor y que humillan y menosprecian a los demás. Estas son las causas del desperdicio. Elimínelas y opte por una forma más suave y menos problemática de hacer las cosas. El Scrum trata precisamente de que las cosas fluyan.
4.- Planifique sobre la realidad, no sobre la fantasía. Antes de planificar, debemos ser conscientes de que no somos buenos planificadores. Las desviaciones respecto de las estimaciones iniciales de la duración de un trabajo pueden llegar a oscilar entre un 25 y un 400 % más. Eso equivale a un rango de error de ocho veces.
De acuerdo, Sutherland —parece que les estoy oyendo decir—, somos muy malos a la hora de realizar estimaciones, pero hay algo que hacer, ¿no? Por supuesto. Lo primero, debemos elaborar una lista con todas las cosas que haya que hacer en un proyecto. A continuación hay que tomar todos estos elementos y clasificarlos por orden de prioridad. Debemos pensar en las cosas que son realmente importantes y trabajar en ellas lo primero. Contar con esta información es esencial, porque si uno empieza a tener problemas con la fecha de arranque o con el presupuesto, sabremos dónde recortar: por el final de la lista.
Así pues, ya tenemos la lista de cosas que hay que hacer y ya hemos priorizado. Ahora el trabajo consiste en pensar cuánto esfuerzo, tiempo y dinero requerirá aproximadamente el proyecto. Como ya he señalado antes, a los seres humanos esto se nos da realmente mal, pero en lo que somos buenos, según parece, es en el dimensionamiento relativo, es decir, comparar un tamaño con otro. Para ello podemos utilizar una escala que se base en la sucesión Fibonacci.
La sucesión Fibonacci no es otra cosa que una secuencia de números en la que uno es la suma de los dos anteriores, es decir, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55… ¿Por qué utilizar estos números para ponderar las tareas? Estos números están lo suficientemente separados para que podamos ver fácilmente la diferencia. Si una persona estima la duración de una tarea en 5, y otra tarea en un 8, podemos percibir intuitivamente la diferencia. Pero ¿y la diferencia entre un 5 y un 6? Eso es mucho más sutil, más de lo que nuestro cerebro puede registrar. Nuestra mente no funciona con incrementos ligeros, sino mediante saltos bien marcados.
La utilización de la sucesión Fibonacci en el cálculo de tareas nos permite hacer estimaciones que no tienen que ser cien por cien exactas. Nada puede ser exacto entre un 5 y un 8 o entre un 8 y un 13, pero usar estos números nos permite dar el siguiente paso: hacer estimaciones en grupo. Con la sucesión Fibonacci todo el mundo puede utilizar más o menos la misma vara de medir y, en ese sentido, se puede crear un consenso.
Hacer estimaciones en grupo proporciona resultados mucho más exactos de los que haríamos por nuestra cuenta. Sin embargo, nos enfrentamos a dos graves problemas: diferentes miembros del equipo saben cosas diferentes, y el llamado el efecto “rebaño”. Todos hemos estado en reuniones como estas: al principio existen opiniones divergentes, pero todo el mundo se pone de acuerdo en seguir un determinado camino porque alguien lo defiende con vehemencia.
Hay un buen ejemplo que ayuda a entender el efecto “rebaño”. Imaginemos que alguien envía un artículo a una revista científica. Supongamos que el editor rechaza el artículo. A continuación, el autor lo manda a una segunda revista. Si el editor de esta segunda revista está enterado de que el artículo ha sido rechazado la primera vez, hay más probabilidad de que también lo rechace. Si existe una tercera revista, hay más probabilidades todavía de que ese editor, sabedor de los dos primeros rechazos, lo rechace a su vez. La gente da por hecho que los demás sustentan opiniones fundadas, incluso aunque dichas opiniones contradigan las suyas. Esto es un auténtico problema en la gestión de proyectos.
Cuando estás tomando una decisión sobre cuándo deberá estar terminado un proyecto de miles de millones de dólares —o la planificación de la reforma de tu casa— es crucial aplicar tu propio criterio, y utilizar las estimaciones de otros para mejorar la tuya, pero no para sustituirla. Para enfrentarnos a este problema utilizo una estrategia basada en el método Delphi para recabar opiniones individuales y anónimas con el fin de estimar la duración de un proyecto. Lo llamo el póquer de planificación.
La idea es simple. En una reunión, cada persona dispone de un mazo de cartas (con los valores de la sucesión de Fibonacci: 1, 2, 3, 5, 8 y 13) y asigna a cada tarea una carta presentada bocabajo. Después de cada mano, las cartas se descubren y se obtiene la media. Si la separación entre dos valores es de más de tres cartas, los jugadores que escogieron la carta más alta y más baja explican por qué lo hicieron y se juega otra mano.
Este método tan increíblemente sencillo sirve para evitar cualquier tipo de comportamiento inmovilista, como el efecto rebaño, y permite que todo el equipo comparta el conocimiento sobre una tarea en concreto. Es crucial, no obstante, que sea el equipo el que de verdad haga el trabajo de la estimación, no un experto en estimaciones “ideales”.
Otro aspecto que debemos tener en cuenta a la hora de confeccionar listas de tareas y asignarlas es la motivación. A este respecto, es importante señalar que no hay tareas, sino historias. Hay que contar para qué y para quién se hacen las cosas. Antes de priorizar, debemos definir al personaje, al usuario, al cliente, a la persona que va a utilizar lo que nosotros vamos a hacer para que quien tenga que realizar una tarea entienda lo que hace y se mantenga motivado. Hacer tu trabajo dentro de un vacío informativo es tedioso y desmotivador.
Trabajar con historias también influirá en la estimación de las cosas. Ah, ¿que quieren simplemente una función de calendario? Eso es fácil. ¿Que quieren un registro de tiempo inalterable con efectos de tipo legal? Eso es un poco más complicado… Además, las necesidades cambian según los personajes. Imaginemos, por ejemplo, una historia cuyo final es: “… quiero un coche para poder ir a trabajar”. Ahora bien, si esa frase empieza diciendo: “Como persona que vive en las afueras” en lugar de “Como granjero que vive en los despeñaderos de Dakota del Sur…”, la interpretación de lo que sería el vehículo ideal para esa persona sería muy diferente. Las historias lo son todo.
Llegados a este punto podemos empezar a contestar a la pregunta de cuándo estarán hechas las cosas. Tenemos las historias, las cosas que hay que hacer. Y las hemos estimado; esto es un 8, esto es un 3, etc. Y luego empezamos nuestro primer sprint. Digamos que dura una semana. Al final de la semana hacemos un recuento de todas las tareas que hemos completado, sumamos los puntos en los que fueron estimadas, y ese número nos dice lo rápido que está yendo el equipo, su velocidad. Una vez que tenemos la velocidad, podemos ver cuántas tareas nos quedan y cuántos puntos representan, y así sabremos cuándo habremos acabado.
Una vez que tenemos nuestra velocidad, podemos hacernos una idea de lo más importante en el Scrum: ¿qué nos está impidiendo ir más rápido? ¿Qué nos está impidiendo acelerar? Antes hablamos sobre el desperdicio, sobre las cosas que nos retrasan. De esta forma es como vemos si realmente estamos consiguiendo librarnos de ese desperdicio.
5.- Aprenda a priorizar. El Scrum no consiste solo en que los equipos trabajen más deprisa. Consiste en potenciar el impacto que consiguen con su trabajo. Por eso, cuando asesoro a una empresa, siempre les digo que deben encontrar el equilibrio entre lo que pueden construir, lo que pueden vender y lo que puede llegar a entusiasmarles. Si te concentras solo en lo que puedes construir, acabas haciendo algo que nadie quiere en realidad. Si te concentras solo en lo que puedes vender, es probable que prometas cosas que no puedes construir. Si solo construyes lo que puedes vender pero no te entusiasma, acabas trabajando duro para construir algo mediocre.
El área de intersección de estas tres zonas es la visión del producto, algo que exige, en primer lugar, establecer el backlog o lista de objetivos pendientes para que sepamos qué hacer y cuándo hacerlo.
El secreto de un buen backlog es que debe englobar lo que teóricamente pueda incluirse en el producto, y su clave es saber lo que hay que hacer primero. Para ello nos preguntaremos qué ítems representan el mayor impacto empresarial, cuáles son los más importantes para el cliente, qué puede generar más ingresos y qué es lo más fácil de hacer. En el Scrum, comenzamos con lo que genera más ingresos de inmediato para eliminar el riesgo del proyecto. Recordemos que el 80 % del valor de algo reside en un 20 % de las características. El Scrum consiste en averiguar cómo crear ese 20 % antes que lo demás.
Pero ¿cómo se hace esto? Con alguien que pueda determinar cuál es la visión y dónde reside el valor. En el Scrum esta persona se denomina responsable de producto (Product Owner). Como podemos ver, en el Scrum solo hay tres roles: miembro del equipo, el Scrum Master (que ayuda al equipo a descubrir cómo hacer el trabajo mejor) y el responsable de producto (que decide qué trabajo debe hacerse). Este último es el “dueño” del backlog, de lo que figura en él y, lo más importante, en qué orden está.
Mi inspiración para esta función fueron los jefes de ingeniería de Toyota, responsables de una línea de producto entera, como la del Corolla o el Camry. No tienen autoridad. Nadie tiene que rendirles cuentas, sino que rinden cuentas a sus propios grupos. La gente puede decirles a los jefes de ingeniería que están equivocados, de modo que tienen que asegurarse de que hacen lo correcto. No evalúan el rendimiento de nadie ni intervienen en ascensos o promociones, pero deciden sobre la visón del coche y cómo habrá que fabricarlo mediante la persuasión, no mediante la coerción. Cuanta mayor experiencia, mejor, pero si carecemos de personas con treinta años de experiencia, podemos subdividir la función asignando al Scrum Master el cómo y al responsable de producto, el qué.
El responsable de producto transmite el feedback del cliente al equipo en todos los sprints. Cuando puse en práctica el Scrum, decidí que el responsable de producto debía pasar la mitad del tiempo hablando con la gente que compra el producto (averiguar lo que piensan acerca de la última versión o demo del producto) y la otra mitad con el equipo que crea el backlog (mostrarles qué es lo que los clientes valoran y qué no). Esto significaba que la persona elegida tenía que ser alguien en quien el equipo creyera y confiara.
Cuando escoges a un responsable de producto, hay que pensar en alguien que sepa ponerse en el lugar de quienquiera que va a obtener valor de lo que estamos haciendo. Como dice un amigo mío: “Mi esposa es la responsable de producto ideal: sabe exactamente lo que quiere. Yo me limito a implementarlo”. El Scrum Master y el equipo son responsables de lo rápido que van y de lo rápido que pueden llegar a ir. El responsable de producto se encarga de traducir la productividad del equipo en valor. La clave está en decidir cuál es la medida del valor. Y puede ser cualquier cosa: conozco equipos de policía que utilizan el Scrum y miden el valor por el número de delincuentes en busca y captura que detienen cada semana, o iglesias que valoran su éxito según si crece o no el número de feligreses.
Después del primer sprint y una vez entregado algún producto, podemos darnos cuenta de que el orden de prioridades puede mejorarse. El orden siempre está fluyendo, pero al mismo tiempo no podemos priorizarlo todo. Como decía Federico II de Prusia: “El que lo defiende todo no defiende nada”. Justo ahí reside otra gran ventaja del Scrum. El feedback continuo facilita el lanzamiento de productos al permitirnos saber qué es lo que más valora la gente. Así, podemos realizar pruebas con algunas características del producto (a través de un prototipo o un producto mínimo viable) mientras seguimos trabajando para crear más valor. El coste de unos pocos sprints adicionales no puede compararse con las pérdidas, muchas veces millonarias, derivadas de la construcción de productos o servicios que a nadie le interesan.
Conclusión
La gente quiere hacer cosas que tengan sentido; quiere hacer del mundo, aunque sea en pequeña medida, un lugar mejor. La clave está en librarse de lo que se interpone en su camino, eliminar los impedimentos para convertirse en lo que es capaz de hacer.
Esto es lo que hace el Scrum. Establece objetivos y, sistemáticamente, paso a paso, va encontrando la manera de llegar a ellos. Y, lo que es más importante, identifica lo que nos impide hacerlo. Si hubiera una sola idea que me gustaría que se recordara del Scrum sería esta: se pueden cambiar las cosas, no tenemos por qué resignarnos a que se queden como están. No haga caso de los cínicos que le dicen constantemente lo que no se puede hacer. Sorpréndales con lo que se puede.
Fin del resumen
Biografía del autor
Jeff Sutherland
Jeff Sutherland es el creador de Scrum. Ha sido vicepresidente de varias empresas de informática y de ingeniería, en algunas de las cuales se ha puesto en práctica Scrum con excelentes resultados. Además, dirige talleres en todo el mundo, comparte sus conocimientos y sus experiencias con numerosas empresas y organismos, e imparte conferencias sobre las normas y la metodología de Scrum.
Descargar Resumen
No tienes el nivel necesariohelp_outline
Hacer QUIZ
Ficha técnica
Editorial: Planeta
ISBN: 9788408135326
Temáticas: Habilidades directivas Gestión del tiempo y técnicas de productividad Mejora de procesos
Comprar el libro
Si has leído el resumen y quieres profundizar más te recomendamos comprar el libro completo, en papel o ebook, haciendo click aquí