Jeff Sutherland y el origen de Scrum
Introducción
Mi primer contacto con Scrum fue en el 2007, desde ese momento he conversado con muchos “expertos” sobre el tema. Es interesante ver cómo cada persona tiene su propia interpretación de Scrum. Muy pronto me di cuenta que esto probablemente se debía a que la guía de Scrum explica el qué pero no el cómo. Algunas opiniones me parecían que tenían toda la lógica y otras por lo menos cuestionables.
En una ocasión durante un viaje a Argentina un experto me dijo “Scrum mejora la felicidad de las personas en el trabajo, el aumento de la productividad no es tan importante, es un efecto secundario”. Yo en mi posición de empresario estuve escéptico con este comentario, dudé que esa fuera la intención de los fundadores de Scrum. Después de varios años de estudiar Scrum y de encontrar varias contradicciones en el concepto decidí que lo mejor era hablar personalmente con el creador de Scrum, Dr. Jeff Sutherland. Al contactarlo logramos programar un entrenamiento juntos en su oficina de Scrum Inc Boston, Massachusetts.
Al llegar a Boston en la última semana de octubre quedé impresionado. Boston es una ciudad con bastante historia, un ejemplo de esto es la famosa Boston Tea Party que marcó un punto importante en el conflicto entre el Nuevo Mundo y Gran Bretaña. También es la ciudad de unas de las mejores universidades del mundo como Harvard o MIT, donde se inventaron muchas de las ideas que hoy lideran el mundo.
El primer día que me encontré con Jeff en su oficina para planear el entrenamiento, lo primero que observe al revisar su material es la cantidad de evidencia empírica que usa para soportar sus ideas, cosa que no encontré en entrenamientos de Scrum en los que estuve anteriormente. El primer día del entrenamiento fue particularmente interesante, Jeff nos habló de cómo inició su prototipo de Scrum, su inicio fue mucho antes del famoso articulo de Harvard Business Review (HBR) en 1986: The New Product Development Game
https://hbr.org/1986/01/the-new-new-product-development-game
El origen de Scrum – antes del artículo de la HBR
Muchos creen que el artículo de Takeuchi y Nonaka en la HBR motivó a Jeff y Ken Schwaber a inventar Scrum. La verdad es que Jeff ha experimentado con el método desde muchos años antes de la existencia de este artículo.
Al finalizar el primer día de entrenamiento salimos a cenar y charlar un poco. Jeff me contó una historia bastante interesante: fue piloto de combate den la guerra de Vietnam, después hizo su maestría en Mathematics and Computer Science en Stanford en 1972 y su doctorado en biométrica y radiología en 1980. Jeff logró combinar el aprendizaje de cada una de sus etapas y experiencias para crear y perfeccionar su método Scrum. Por ejemplo, cuando Jeff trabajó para Dennis Ritchie (inventor de C y Unix) en Bell Labs, vio un estudio de un equipo fuera de serie al ser 52 veces más rápido que otros equipos debido a sus alta saturación de comunicación, gracias a esto es que hoy existe el Daily Scrum. Otro ejemplo que citó fue cuando él trabajaba en un banco y se le asigno la peor unidad de negocio, cuando inicio a aplicar su prototipo de Scrum las cosas empezaron a mejorar y en 6 meses se convirtió en una de las mejores unidades del banco. Muchas de sus ideas nacieron años antes de artículo en la HBR pero fue este famoso artículo que dio el nombre a este método.
En su libro: “Scrum. El arte de hacer el doble de trabajo en la mitad de tiempo
Recomiendo fuertemente este libro a todos antes de interpretar la guía de Scrum.
La versión digital se consigue desde 0.99 dólares aquí:
Jeff’s objetivo para Scrum
Una cosa me quedó muy clara después de todas las conversaciones compartidas con Jeff, su intento con Scrum fue aumentar la productividad (o la velocidad como lo llamamos en Scrum). El título de su libro dice no solo un poco sino: hacer el doble de trabajo en la mitad del tiempo. Entonces en mi opinión cualquier interpretación de Scrum debe tener en cuenta esta idea principal
Jeff Sutherland y Fabian Schwartz, Boston 2016
Interpretar Scrum bien
Es evidente que existen varias implementaciones de Scrum que no funcionaron y según mi apreciación se debe principalmente a uno de los siguientes errores: 1) hacer ajustes a Scrum que contradicen la guía de Scrum o 2) Interpretar mal la guía (usualmente es la parte de cómo hacer las cosas). Entonces la pregunta es, ¿cómo se puede evitar esto? Personalmente creo que es muy valioso saber por qué cada elemento de Scrum existe y para esto les recomiendo el libro de Jeff.
Un ejemplo de lo anterior es el concepto de felicidad que escuche del experto en Argentina, Jeff también habla de felicidad pero en un sentido diferente. Él se basa en un estudió de Harvard en el que se dice que empleados que son más felices tienen mayor productividad, Así, él propone medir la felicidad de los empleados con el fin de aumentar la productividad.
Es importante seguir la guía de Scrum sin cambiar o ajustar los elementos o agregar cosas de mas que no son necesarias. Según Jeff la guía de Scrum es parecida al sector de arranque (bootsector) de un computador. Cambiando solo un bit puede resultar que el computador no encienda. Cosas como el ScrumBOK de otra organización son muy cuestionables en términos de su éxito y les recomiendo usar la guía oficial de Scrum.
La guía de Scrum pueden bajar gratis aquí:
Finalmente, para la parte de cómo hacer las cosas existen los patrones (pattern). Un patrón es una buena práctica que ha mostrado su éxito empíricamente. Por ejemplo, un patrón es el Swarming que dice que todo el equipo debe que trabajar junto en la primera tarea más importante antes de pasar a la siguiente.
Aquí pueden encontrar los patrones:
Resumen
En resumen, la idea de Scrum ya existe desde muchos años antes que la Guía de Scrum y es bueno conocer un poco de esta historia para entender cuál es el objetivo de esta misma. Fue muy valioso para mi, entrenar junto a Jeff y escuchar su punto de vista y su experiencia. Me permitió clarificar mi propio entendimiento de Scrum e identificar las malas interpretaciones.
Celia
Muy bien explicado.